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1. Acronyms 

AERCam - Autonomous Extravehicular 
Robotic Camera 

ATLAS - Atmospheric Laboratory for 
Applications and Science 

ATV - Automated Transfer Vehicle 

BET - Besf Esfimafe of Trajectory 

BFS - Back-up Flighf Sysfem 

BIT - Builf In Tesf 

BITE - Builf In Tesf Equipmenf 

CANDOS - Communicafions And Navigafion 
Demonsfrafion On Shuffle 

CHAMP - CHAIIenging Minisafellife Payload 

CO AS - Crew Opfical Alignmenf Sighf 

COTS - Commercial Off The Shelf 

CRISTA-SPAS - CRyogenic Infrared 

Specfromefers and Telescopes for 
Afmospheric - Shuffle PAIIef Safellife 

CRV - Crew Refum Vehicle 

DART - Demonsfrafion of Autonomous 
Rendezvous Technology 

DPS - Descenf Propulsion Sysfem 

DTO - Defailed Tesf Objecfive 

EGI - Embedded GPS/INS 


EGNOS - European Geosfafionary Navigafion 
Overlay Service 

FDIR - Faulf Defecfion Idenfificafion and 
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FOM - Figure Of Merif 

GANE - GPS Affifude and Navigafion 
Experimenf 

GDOP - Geomefric Dilufion of Precision 

GEM - GPS Embedded Module 

GEE - Governmenf Furnished Equipmenf 

GLONASS - Global Navigafion Safellife 
Sysfem 

GNG - Guidance, Navigafion and Gonfrol 

GNSS - Global Navigafion Safellife Sysfems 

GPG - General Purpose Gompufer 

GPS - Global Posifioning Sysfem 

GRAGE - Gravify Recovery And Glimafe 
Experimenf 

HAINS - High Accuracy Inerfial Navigafion 
Sysfem 

HHL - Hand Held Laser 

HTV - H-II Transfer Vehicle 

HUD - Heads Up Display 

IGD - Inferface Gonfrol Documenf 
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IMU - Inertial Measurement Unit 


PASS - Primary Avionics Software Subsystem 


INS - Inertial Navigation System 

ISS - International Space Station 

IV&V - Independent Verification and 
Validation 

JSC - Johnson Space Center 

JPALS - Joint Precision Approach and Landing 
System 

KSC - Kennedy Space Center 

LAAS - Local Area Augmentation System 

LPT - Low Power Transceiver 

MAGR/S - Miniaturized Airborne GPS 
Receiver/Shuttle 

MGS - Master Gontrol Station 

MLS - Microwave Landing System 

MOD - Mission Operations Directorate 

MOTS - Modified Off The Shelf 

MSBLS - Microwave Scanning Beam Landing 
Sysfem 

OAST - Office of Aeronaufics and Space 
Technology 

OMS-2 - Orbifal Maneuvering Sysfem 2 

ORFEUS-SPAS - Orbiting and Refrievable Far 
and Exfreme Ulfraviolef Specfromefer 
- Shuffle PAllef Safellife 


PRN - Pseudorandom Noise Gode 

QA - Qualify Assurance 

RAIM - Receiver Aufonomous Infegrify 
Moniforing 

RLG - Ring Laser Gyro 

RM - Redundancy Managemenf 

SA, S/A - Selective Availabilify 

SEM-E - Sfandard Elecfronic Module, Formal 
"E" 

SIGI - Space Infegrafed GPS/INS 

SOAR - SIGI Orbifal Affifude Readiness 

SPARTAN - Shuffle Poinfed Aufonomous 
Tool for Asfronomy 

SPOT - Spacecraff Position Opfimal Tracking 

SRTM - Shuffle Radar Topography Mission 

STS - Space Transporfafion Sysfem 

TAGAN - Tactical Air Gonfrol And 
Navigation 

TAL - Trans Aflanfic Landing 

TANS - Trimble Advanced Navigation Sysfem 

TGS - Trajecfory Gonfrol Sensor 

TDRSS - Tracking and Dafa Relay Safellife 
Sysfem 
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TSO - Technical Standard Order 

UAV - Unmanned Aerial Vehicles 

UHF - Ultra High Frequency 

VHF - Very High Frequency 

WAAS - Wide Area Augmentation System 

WSF - Wake Shield Facility 

X-SAFT - X-38 SIGI Atmospheric Flight Test 

XSS - Experimental Spacecraft System 
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2. Preface 


This document is a collection of writings concerning the application of Global Posifioning Sysfem (GPS) 
fechnology fo fhe Infemafional Space Sfafion (ISS), Space Shuffle, and X-38 vehicles. An overview of how 
GPS fechnology was applied is given for each vehicle, including rafionale behind fhe infegrafion 
archifecfure, and rafionale governing fhe use (or non-use) of GPS dafa during flighf. For fhe convenience 
of fhe reader, who may nof be inferesfed in specific defails of fhe ISS, Shuffle and X-38 applications, fhe 
lessons learned chapfer is af fhe beginning of fhe documenf. Mosf of fhis maferial can be understood 
wifhouf reading fhe secfions specific fo fhe ISS, Shuffle and X-38. 

These lessons were written mainly from fhe perspective of NASA and confracfor personnel (bofh 
fechnical and managemenf) supporting fhe Mission Operafions Direcforafe af fhe Johnson Space Genfer 
(JSG). Additional perspective on GPS infegrafion experiences and lessons learned can be obfained by 
confacfing fhe JSG Aeroscience and Flighf Mechanics Division, Gode EG (Engineering Direcforafe). 

GPS has also been applied fo space applications by ofher NASA confers (Goddard, Jef Propulsion Lab, 
Marshall). Personnel supporting GPS applications af fhese centers can also provide insighf info 
challenges associated wifh GPS infegrafion. 
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3.1 ntroduction 


In the early 1990s, use of Commercial or Modified Off The Shelf (COTS or MOTS) hardware and soffware 
became a prominenf fheme in governmenf and indusfry in order fo reduce procuremenf, developmenf 
and infegrafion cosfs. Af fhe same fime, in an affempf fo revifalize fhe U.S. space program, a "fasfer- 
beffer-cheaper" approach fo spacecraff developmenf and mission execufion was being sfressed wifhin 
NASA. 

By fhe early 1990s, after over 20 years of developmenf of fhe Global Posifioning Sysfem, fhe GPS safellife 
nefwork and associafed ground supporf infrasfrucfure was nearing operafional sfafus. GPS receivers for 
scienfific, commercial, consumer and milifary applicafions were enfering the marketplace. GPS was 
anticipated to provide the revolutionary capability of precision navigafion af low cosf and af a minimum 
amounf of efforf on fhe parf of fhe user. GPS receivers have fhe pofenfial fo provide cheaper, more 
accurafe and fimelier sfafe vecfors fhan fradifional ground fracking. GPS is an enabling fechnology for 
small safellifes operafed by organizafions fhaf cannof supporf an operafions infrasfrucfure. To lower 
spacecraff operafing cosfs, fhere is a desire fo build spacecraff fhaf operafe in a more autonomous fashion 
and require fewer or no ground supporf personnel. 

Af fhis fime, fhe NASA Johnson Space Genfer inifiafed a number of projecfs designed fo leverage GPS 
fechnology fo meef fhe needs of currenf and fufure manned spacecraff. Use of oft-fhe-shelf GPS receivers 
was believed fo be fhe key fo infroducing low cosf, precision navigafion info human space flighf, and fo 
reduce infegrafion, cerfificafion, and maintenance cosfs. These spacecraff included fhe Space Shuffle [1], 
fhe ISS [2] and fhe X-38 [2, 3], a profofype of a Grew Refurn Vehicle (GRV) for fhe ISS. The receiver 
infegrafed info fhe Space Shuffle avionics sysfem was fhe Miniafurized Airborne GPS Receiver/Shuffle 
(MAGR/S), while fhe ISS and X-38 used fhe Space Infegrafed GPS/Inerfial Navigafion Sysfem (SIGI). In 
addifion, a mission confrol soffware fool called fhe Spacecraff Posifion Opfimal Tracking (SPOT) filter 
was developed fo process Shuffle and ISS GPS receiver dafa fo provide more accurafe orbif deferminafion 
for mission planning. The use of GPS by fhe Shuffle, ISS and X-38 is nof as extensive as some mighf 
expecf, given fhe widespread use and success of GPS fechnology, and fhe availabilify of ~$100 receivers fo 
fhe general public. The rafionale behind fhe currenf planned use of GPS by fhe Shuffle and ISS Programs 
is discussed along wifh some projecf history. 

While fhe Shuffle and ISS infegrafions were successful (fhe X-38 was canceled), more technical and projecf 
managemenf challenges were encounfered fhan anficipafed. More GPS receiver soffware changes, hosf 
vehicle flighf soffware changes, and flighf and ground fesfing were required fhan anficipafed, which in 
torn caused schedules fo slip. 

Two incidenfs involving GPS, one on fhe ISS and anofher on fhe Space Shuffle, had a profound effecf on 
fhe direcfion and execufion of fhe GPS infegrafions. During fhe STS-91 (June 1998) flighf of Discovery, a 
GPS receiver soffware problem inferacfed in an unanficipafed manner wifh exisfing Shuffle flighf 
compufer soffware requiremenfs which were deficienf and resulted in a loss of communicafion wifh 
Discovery for over an hour. 
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On the ISS in September of 2002, a GPS receiver software error not recognized in ground testing caused 
an ISS computer system to go into a diagnostic mode. The incident impacted the ISS in the following 
ways: fransfer of affifude confrol from fhe U.S. segmenf confrol momenf gyros fo fhe Russian segmenf 
fhrusfer sysfem; confingency affifude confrol using valuable and carefully managed propellanf supplies; 
labor infensive manual S band anferma poinfing by Mission Confrol in Houston fo mainfain dafa and 
voice communicafions; loss of Ku band dafa fransmission capability; loss of micro-gravity environment 
due to attitude control thruster firings; and loss of a crew day of science operafions. 

Shuffle GPS receiver. Shuffle compufer and ISS GPS receiver soffware changes were lafer made. Lab 
fesfing and flighf experience proved fhaf fhe changes resolved fhe soffware problems. 

GPS receiver procuremenf, pre-flighf fesfing, infegrafion, numerous fesf flighfs in space and on aircraft, 
data analysis, issue resolution, interaction with the GPS community (vendors, users and satellite 
operations persormel), and participation in navigation industry conferences has provided Johnson Space 
Center persormel wifh insighf info fhe advanfages and difficulfies posed by GPS fechnology. Many 
observations and lessons learned from fhese projecfs may be useful for reducing risk in ofher GPS 
implemenfafions, and any projecf fhaf concerns fhe infusion of soffware infensive fechnology. 

Fufure applicafions such as formafion flying, eliminafion of ground fracking, aufonomous operafion and 
aufomafed orbifal replenishmenf (rendezvous, proximity operations and docking) will place stringent 
demands on GPS receivers. Software quality, hardware reliability and orbit determination accuracy 
requirements to support these applications will be more demanding than the capabilities of currenf, 
Commercial-Off-The-Shelf (COTS) based GPS unifs. Lessons learned from experiences in fhe Shuffle, ISS 
and X-38 programs should be sfudied fo mitigate risk in fufure programs fhaf require highly accurafe, 
robusf GPS navigation and GPS affifude deferminafion fo supporf aufomafion and autonomy 
requiremenfs. 
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4. The Software Nature of Satellite Navigation 


Threats to I ntegrity 

Risks to GPS (or GNSS, Global Navigation Satellite Systems) integrity include radio-frequency 
interference (infenfional or uninfenfional), spoofing, ionospheric and solar effecfs, user errors, mulfipafh, 
signal obscurafion, anfenna failure, failures in compufers fhaf inferacf wifh GNSS receivers, and 
malfuncfioning GNSS safellifes or ground supporf sysfems [4]. The effecfs of on-board safellife 
equipmenf failures, or ground confrol segmenf induced anomalies, may affecf users over a wide area. 
Specfrum sharing and fhe effecfs of new radio-frequency fechnologies, such as Ulfra Wide Band, are 
imporfanf issues fhaf musf be resolved af fhe engineering, govemmenf policy and regulafory levels. The 
navigafion indusfry and govemmenf agencies are acfively researching fhe pofenfial of GNSS infegrify 
fhreafs and building sysfems (such as WAAS, LAAS, EGNOS) and procedures fo defecf, idenfify and 
mifigafe fhem [5]. Much research has been performed on receiver algorifhms (such as Receiver 
Aufonomous Infegrify Moniforing, or RAIM) fo defecf signal-in-space issues [6]. 

These are nof hypofhefical fhreafs. On July 28, 2001, fhe failure of a rubidium clock on GPS safellife PRN 
22 was defecfed by fhe WAAS, fhe U.S. Goasf Guard and GPS receivers fhaf were equipped wifh RAIM 
algorifhms [7]. A well-publicized example of uninfenfional inferference was noficed in Moss Landing 
Harbor, Galifomia, in April of 2001. Several monfhs of invesfigafion resulfed in fhe idenfificafion of fhree 
boaf mounfed, acfive UHFA^HF felevision anfennas wifh preamplifiers, fhaf were fhe source of fhe 
inferference [8]. 

Software Quality and GNSS I ntegrity 

Over fhe lasf 40 years, infegrafion of off-fhe-shelf sysfems had changed from being primarily hardware 
infegrafion fo soffware infegrafion. This presenfs new challenges for users of off-fhe-shelf sysfems. 
Developers of such sysfems musf compefe in a markef fhaf demands shorf fime-fo-markef and low 
overhead. This resulfs in shorf developmenf and fesf cycles, less rigorous requiremenfs definifion and 
documenfafion, and a small group of programmers; and if can lead fo a higher probability of soffware 
errors. Some producfs confain legacy code fhaf may be decades old, and proper coding sfandards may 
nof have been adhered fo. Vendors offen mainfain a library of common soffware modules used in a 
variefy of producfs. Gosf and schedule concerns may lead fhe vendor, infegrafor, or user fo judge a 
soffware issue fo be no impacf and nof fix if. However, fhis can lead fo propagafion of soffware problems 
fhroughouf a producf line, and if could negafively impacf users whose applicafions of fhe producf in 
question are differenf from fhe original user. 

Hisforically, navigafion unif problems and failures in fhe legacy Shuffle navigafion sysfem fended fo be of 
a hardware nafure. However, mosf problems observed by JSG wifh GPS have concerned soffware. GPS 
receivers confain fens or hundreds of fhousands of lines of code. Gode errors may nof always manifesf in 
a predicfable or easily observable manner and may lie dormanf for years unfil fhe proper sef of 
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conditions permits them to become visible. Software errors that do not manifest in an aircraft application 
of a GPS receiver may be an impacf in orbif, where vehicle dynamics, safellife visibility, and flight times 
are very different. 


Software is at the heart of fhe GNSS revolution. Receivers, ground monitoring sfafions, augmenfafion 
sysfems, GNSS satellites and associafed constellation ground support equipment are software intensive. 
The computational capacity and amount of code possessed by GNSS receivers is approaching fhaf of 
aircraff flighf managemenf sysfems and flighf confrol computers. Some currenf and many fufure GNSS 
receivers will inferface wifh multiple sysfems: GPS, Galileo, GLONASS, WAAS, LAAS, EGNOS and 
various differential sysfems. Multiple system interfaces will furfher increase fhe soffware complexify of 
GNSS receivers. With this revolutionary navigation capability has come increased potential for 
performance anomalies due to soffware issues. 

Receiver soffware problems can resulf in degraded navigation accuracy, or loss of navigation dafa for a 
variable amounf of time. Mosf of fhe fhreafs under examination by fhe navigation indusfry and 
govemmenf agencies are external fo GNSS receivers. External moniforing, augmenfafion sysfems and 
receiver based RAIM will profecf againsf soffware failures external fo fhe GNSS receiver, buf will nof 
profecf a user from a GNSS receiver soffware problem. 

Receiver failures are nof always well documented and may nof be noficed if a device is nof continuously 
monifored and dafa is nof recorded and analyzed. If a problem is noficed, fhe reporfs of fen fend fo be 
anecdotal in nature. It is difficult to pin down the cause of many GNSS receiver issues (i.e., intentional or 
unintentional radio-frequency inferference, multipath, signal obscuration, antenna failure, hardware 
failure, receiver soffware failure, hosf compufer hardware or soffware issues, operafor error). Users are 
sometimes foo quick fo blame a receiver problem on a "bad" safellife or receiver soffware "bug," when 
fhe roof cause is more likely a user error sfemming from inadequate knowledge of receiver operation. 

Engineers offen underestimate fhe complexify of soffware, and overesfimafe fhe effectiveness of fesfing 
[9]. Tasks in GNSS receivers are sfarfed and stopped based on priorifies, and fhe abilify fo hack GNSS 
safellifes. Logic pafh execution in a receiver is dependanf on fhe radio-frequency environment, 
introducing an element of randomness info what code is executed, and when. A number of Shuffle 
receiver problems identified during a GPS receiver code audif were deemed non-credible due fo fhe 
number of condifions fhaf had fo occur wifhin a tighf fimeframe. However, many of fhese issues later 
manifested in Shuffle flighfs, sometimes more than once. Receiver software modifications were made, 
proven in lab testing and during Shuttle missions, and the Shuttle GPS system was certified for 
operational use in Augusf of 2002. GNSS safellife signal generators used in lab testing cannot duplicate 
the exact radio-frequency environmenf encounfered oufside fhe lab. Receiver soffware anomalies fhaf 
manifesf in flighf may nof manifest in ground testing. The Shuttle and ISS experience also indicates that 
changes to receiver software can result in subtle, unintended changes in receiver performance. 

Ghanges in operating environmenf fhaf come with a new application may invalidate assumptions made 
during initial requirements definition, and result in software issues during testing and operation. 
Software development schedules driven by time to market pressures and a desire to lower overhead 
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costs (a small group of requirements developers and programmers, short development and test cycles) 
negatively effect software quality. A recent study of stand-alone TSO C-129 certified GPS receivers 
performed in the United Kingdom found that the probability of a receiver outage (loss of service) due to a 
software problem was higher than a signal-in-space problem that RAIM is designed to detect and isolate 
[10]. Data analyzed was collected during a total of 78,384.1 hours of receiver operation. The study 
concluded that more attention should be paid to characterizing GNSS receiver outage probability and 
outage modes. NASA's experience with the Shuttle, ISS, and GRV GPS receivers supports these findings. 


Computer I ntegration Versus Plug and Play 

Many applications of GNSS receivers involve interfacing with other computer systems. The concept of 
"plug and play" assumes that no software or hardware changes are required during integration. This is 
not a safe assumption for many applications. Different users may have different data and commanding 
requirements, and may not be able to economically change the rest of the system to conform to available 
receiver input and output. Hardware changes for items such as mounting or electrical power may also 
be required. Interactions of receiver software and software in other parts of a system cannot be assessed 
without testing and design insight, no matter how many applications already use the receiver in 
question. A "plug and play" integration assumption, which drives initial budget and schedule planning, 
can easily result in schedule slips and cost increases due to unanticipated technical problems at the 
component and system levels. 

Successful integration of computers requires knowledge, not just of the interfaces, but also of how the 
data behind the interfaces are computed and behave under nominal and off-nominal conditions. An 
integrator may have to negotiate legal agreements concerning access to proprietary documentation with a 
vendor, so that information needed for integration is available. Integrator verification of interface 
documentation in a laboratory environment is prudent. System problems may result from the 
inappropriate interaction between parts of a system, such as computers, rather than individual units. The 
root causes, manifestations and impacts of system components that behave in a dysfunctional manner are 
difficult and sometimes impossible to predict. 
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5. GPS Lessons Learned 


Since 1993 numerous flights of GPS receivers have been made on the Space Shuttle (Table 1) in support of 
Shuttle navigation upgrades, testing for the International Space Station, X-38, X-33 and X-34 programs, 
relative GPS technology development, and various other payloads and projects. In addition, GPS has 
been in operational use on the ISS since April of 2002. GPS units are flying on the Shuttle Training 
Aircraft, and flew on X-38 landing demonstration vehicles when dropped from the NASA B-52B at 
Edwards Air Force Base. X-38 GPS tests were also conducted on a NASA Beechcraft Beech 200 Super 
King Air based at the NASA Dryden Research Genter. This experience base can be leveraged to mitigate 
risk in new applications of GPS technology to space flight. 


Table 1 - GPS Flights on the Shuttle and Shuttle Payloads (1993 to 2005) 


Purpose 

Unit Flown ^ 

Flights 

Space Shuttle 

3M 

61, 59, 68, 67, 69, 72, 77 

Navigation 

MAGR 

79, 81, 82, 84, 85, 89, 91, 95, 88, 96, 103, 99, 101, 106, 92, 

Upgrades 

SIGI (GEM III) 

97, 98, 102, 100, 104, 105, 108, 109, 110, 111, 112, 113, 107, 114 
86, 89, 91, 95, 88, 96, 103 

ISS Testing 

TANS Vector 

77(GANE) 


SIGI (Force 19) 

101 (SOAR), 106 (SOAR) 

X-38 Testing 

SIGI (Force 19) 

100, 108 

X-33 & X-34 

LN-IOOG (GEM III) 

81, 86 

Support 

H-764G (GEM III) 

84 

Relative GPS 

TurboRogue 

69 (WSF-02) 

Test 

3M 

69 

ATV Relative 

Laben Tensor 

80 (ORFEUS-SPAS 2), 84S 86^ 

GPS Test 

TANS Quadrex 

80 

Other Payload 

Actel 

51 & 80 (ORFEUS-SPAS 1 & 2) 

Support or 

Blackjack 

99(SRTM) 

Technology 

Low Power 


Demonstration 

Transceiver 

107 (CANDOS) 


TANS Quadrex 

51, 56, 66 (ATLAS 3) 


TANS Vector 

66 & 85 (CRISTA-SPAS 1 & 2), 72 (SPARTAN-206 OAST-Flyer) 


= For Embedded GPS/INS units, the GPS receiver is in parenthesis. 

>>Payioad names are in parenthesis. ATLAS 3, GAME, SOAR, SRTM and CANDOS remained on the orbiter, the 
others were depioyed and retrieved. There may have been other GPS equipped payioads that are not iisted. 
cA Motoroia Viceroy receiver was on the Mir space station. 


The Shuttle, ISS and X-38 GPS projects encountered technical, schedule and budget problems that were 
not anticipated. GPS technology proved to be more difficult to apply than was anticipated in the early 
1990s. In spite of the challenges, the Shuttle and ISS GPS projects eventually resulted in certified GPS 
receivers for operational use. 
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A number of lessons were learned during the requirements definition, integration, testing, certification, 
and operational phases of these projects. Consideration should be given to these lessons learned in any 
future application of GPS to space vehicles. 

Perhaps the most important lesson concerned people's perception of the maturity of GPS technology for 
space applications. The widespread success of GPS in myriad applications during the 1990s exceeded the 
expectations of those in the military navigation arena that designed and developed the system in the 
1970s and 1980s. The success seen in terrestrial applications of GPS was anticipated to occur in space 
applications, but more difficulty in the space applications was encountered than many expected. 
Optimism about the ease of application of GPS to space flight influenced budget, scheduling and project 
planning, which led to problems at both the technical and project management levels as the projects 
progressed. 

A paper presented at a 1998 Institute of Navigation conference covered the status and future plans for 
GPS on spacecraft. Part of the paper discussed reasons for difficulty encountered in development and use 
of GPS receivers for space flight: 

"While this technology holds great promise, its incorporation on spacecraft has been delayed for several reasons. 

. The tremendous success of the very lucrative terrestrial GPS market has, in fact, stifled the development of 

spaceborne GPS receivers. Companies with GPS expertise are more interested in the lucrative terrestrial-based GPS 
market. They are not interested in diverting their GPS talent on the relatively small space-based market. This has 
restricted the development of spaceborne receivers to meet the demands of future spacecraft requirements." [11] 

The paper went on to list the reasons why spaceborne GPS receivers have not matured as fast as receivers 
for terrestrial applications: the perception that GPS technology is mature and requires no research and 
development to fly in space; more lucrative GPS receiver market for terrestrial-based applications; 
differences between space-based and ground-based GPS reception; and the requirement for numerous 
flight experiments to climb the technological stair steps [11]. 


Mission I mpacts Of GPS Problems 


Government and the navigation industry have devoted a considerable amount of effort to ensuring the 
integrity and availability of satellite navigation to the user community to ensure safety [5]. However, the 
negative impact of GPS receiver malfunctions is not limited to safety-of-flight applications such as the 
Space Shuttle or commercial airliners. GPS on the ISS is not safety critical, but frequent Mission Control 
and crew intervention to resolve GPS receiver anomalies created additional work for crew and ground 
personnel. The September 2002 incident on the ISS also impacted science operations, and could have 
posed a risk to crew and vehicle safety due to the communications problems that occurred. In addition 
to the operations costs incurred from handling GPS receiver anomalies, a significant amount of effort was 
required to eventually resolve those anomalies. The interaction of requirements deficiencies in a GPS 
receiver and Shuttle computer software caused a one-hour loss of communications with Discovery during 
STS-91, and drove the Shuttle Program to make significant changes to the Shuttle GPS project. 
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Receiver issues and a lack of design insight negatively impacted several relative GPS technology 
demonstrations on the Shuttle [12-15]. The GEOSAT Follow-On (GEO) Altimetry Mission satellite (not a 
part of the Shuttle Program) was to use a combination of on-board GPS receivers and ground laser 
tracking (using an on-board comer cube reflector) to perform centimeter level orbit determination. 
However, GPS receiver issues forced the use of ground-based lasers alone [16]. 

The criticality of GPS to the success of the Shuttle Radar Topography Mission (SRTM) on STS-99 
(Febmary 2000) led to the inclusion of two Blackjack receivers in the Shuttle payload [17]. The Shuttle 
MAGR/S was designated as a backup, and a second MAGR/S was carried to provide additional backup 
capability. Shuttle IMU and Mission Gontrol processed Tracking and Data Relay Satellite System 
(TDRSS) tracking data were also identified as backups. While the Blackjack met a 60 cm positioning 
requirement, the effort spent on backup orbit determination methods underscores the importance of GPS 
to the success of a non-safety critical science application. GPS was also a critical part of the NASA 
sponsored Demonstration of Autonomous Rendezvous Technology (DART) mission. The DART vehicle 
carried two different GPS receivers (each from a different vendor) to ensure state vector availability [18].’^ 


Define Realistic Schedule, Budget, and Requirements 

The phenomenal success of mass produced, low cost GPS technology in the 1990s is evidence that it can 
be leveraged to provide more robust, economical and autonomous navigation for many different 
applications. This has led some to believe that applying GPS to spacecraft should be relatively 
straightforward, and require little expenditure on development, modification and integration. Many 
potential users of GPS technology fail to realize the complexity of GPS receivers, since some units can fit 
into a pocket and cost around $100. Experience has proven that GPS integration on spacecraft is not so 
straightforward. 

Overly optimistic expectations of the budget and schedule required for integration are often not fulfilled. 
More technical issues were encountered than were anticipated, driving up costs and slipping delivery 
schedules. Particular attention should be paid to how realistic the schedule is considering the complexity 
and technical risk involved. A study by the Aerospace Gorporation of NASA projects that used a faster- 
better-cheaper approach indicated that mission failures resulted from highly complex projects on short 
development timelines [19-21]. 

Analysis at the start of a project should be conducted to determine risk to cost and schedule based on the 
technology level, the maturity of the technology and the difference between the planned application and 
the application for which the receiver was originally designed. Software complexity should also be 
examined. Technical risk must be taken into account when defining budget and schedule. Failure to do so 
can lead to cost and schedule problems [22]. Traditionally, navigation unit integration has revolved 
around hardware integration and testing (such as shock, vibration, thermal, radiation). However, with 
the increasing use of embedded computers software development, maintenance, and testing must be 
budgeted for as well. 


When this document was submitted for publication, the report of the DART Mishap Investigation Board had not 
been publicly released. See "NASA Announces DART Mishap Investigation Board Members," NASA Press 
Release 05-105, April 22, 2005. 
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If extensive modifications and operation in a different environment are required, more testing will have 
to be performed. Provision for interim software versions should be provided in the budget. The vendor 
will have to be more involved than on "plug and play" integrations. Understanding the design rationale 
and original user requirements is important, and provision for discussing this with the vendor should be 
included. 

Lessons learned from users of the same or similar products should be considered, particularly when 
defining requirements for the COTS item. "Loose" requirements may be easily met with little or no 
budget impact. However, they could permit problems to go unnoticed and unresolved and could impact 
future use of the device. Such requirements result in a "let's see what we can get by with" attitude rather 
than a "let's do what is right for the application" approach. 

Some GPS receivers used on NASA spacecraft have a specified rate of receiver resets to recover from 
software anomalies of less than one per day [17]. Such a requirement, along with a maximum allowable 
solution outage time, will help motivate a vendor to pursue software issues. 


Off-The-Shelf Versus Development 

Everything I s Not Plug and Play 

The fact that a unit is in mass production and is a proven product does not mean that its integration into 
a different vehicle will be a simple, problem free "plug and play" project. A difference in application 
(such as aviation versus space flight) will result in the manifestation of software issues that may not have 
appeared in the original application. A unit is not likely to meet all requirements as is, and both software 
and hardware modifications may be needed to meet mission unique requirements and interface with host 
vehicle avionics, telemetry and power systems. Even a receiver originally designed for space applications 
may require changes to meet new requirements and resolve technical issues. 

Changes Will Be Needed 

Navigation and avionics units are becoming more software intensive, and the technical risk posed by 
software is difficult to assess. While GPS receivers have the potential to provide spacecraft with an 
autonomous precision orbit determination capability, most receivers do not contain navigation 
algorithms needed for this [23]. In addition to software concerns, "terrestrial" and "atmospheric" 
navigation units may have difficulty meeting hardware requirements for space flight in the areas of 
loads, thermal, data interfaces, electrical power, weight and volume. The ever-smaller size of electronics 
makes them more vulnerable to space radiation; hence radiation hardening, which is expensive, may 
have to be considered. The Shuttle MAGR/S unit, which represented an early 1990s technology level, met 
NASA space radiation requirements as built. However, SIGI units required expensive modification to 
meet radiation requirements. The GPS receivers on the NASA Gravity Probe B spacecraft are another 
example of modification of a receiver to meet unique mission requirements [24]. 
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A Fixed Price Contract May Not Be Appropriate 


A fixed price contract may be appropriate if the intended application of the device is the same or very 
similar to the application for which it was originally designed. In this case, little or no development work 
is required. However, if a unit is to be used in a flight environment that will necessitate significant 
changes to the device, the program budget and schedule should be allocated as for a development 
project. Fixed price contracts can result in inflated vendor estimates for initial cost and can remove the 
incentive to aggressively resolve technical issues. Resolution of these issues may not be covered in the 
budget defined at project start. Modifying an existing GPS receiver, even one originally designed for 
space, for use on an unmanned or manned spacecraft should be budgeted and scheduled as a 
development project. 

Building Your Own Receiver May Be An Option 

For some scientific applications, commercially available receivers may not meet mission requirements 
(accuracy, fully autonomous operations, special types of measurements, radiation exposure, size, power, 
etc.). Furthermore, such missions may have unique requirements that are difficult to meet with GPS 
receivers whose software is proprietary. One such vehicle is the NASA Johnson Space Genter Miniature 
Autonomous Extravehicular Robotic Gamera (Mini AERGam), a 7.5-inch diameter robotic inspection 
nanosatellite [25]. GPS vendors may be reluctant to support customization (i.e. a research and 
development activity) of a small number of receivers, for which a market does not exist. An example of 
an in-house scientific receiver is the Jet Propulsion Laboratory Blackjack, which has flown on IGESat 
(2003), EedSat (2002), GRAGE (2002), JASON-1 (2001), SAG-G (2000), GHAMP (2000), and SRTM/STS-99 
(2000) [26]. 

Gommercially available GPS receiver kits supply GPS chip sets and traditional GPS software functions 
(signal processing, channel and data management, etc.) while allowing the user to add application 
unique software. Another advantage to kits is that the user has access to all software source code. 

However, building and flight qualifying an in-house receiver for space flight requires a high level of in- 
house GPS hardware and software expertise. Required skills that are not in-house may have to be 
obtained via contractors. Many projects may not have the schedule, budget, and technical resources 
needed to custom build a GPS receiver. Even if an off-the-shelf unit requires extensive modification, 
such a path may be less expensive than a custom built receiver or adaptation of a commercial GPS 
receiver kit. Eor safety-critical applications, such as the Space Shuttle, use of off-the-shelf units may be 
more appropriate. GPS vendors can leverage experience from a variety of safety critical government and 
commercial programs. Eurthermore, some capabilities (such as ground or satellite based augmentation, 
authorized operation, mitigating radio-frequency interference, etc.) needed for receivers in safety critical 
integrations may require expertise that may not exist outside of the vendors. Vendor expertise and 
experience is crucial to successful requirements definition, receiver modification, integration, testing, 
anomaly resolution and certification of a safety critical receiver. 
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Working With Off-The-Shelf Items 


Recent analyses indicate that a lack of guidance on the application of COTS and fasfer-beffer-cheaper 
principles leads fo projecfs fhaf exceed cosf and schedule esfimafes, and in some cases causes projecf 
failure [9, 10]. Some projecfs have failed or encounfered significanf problems since management and 
technical personnel were told to use COTS, but were not given (or did not seek) guidance on how to 
work with COTS, or determine if a COTS approach was even feasible. While much maferial has been 
published on fhe subjecf of COTS, much of if is highly fheorefical. Many managers and engineers 
concerned wifh using COTS do nof necessarily have the theoretical background to understand esoteric 
treatments of COTS theory. A key lesson from accidenf reports and experience papers reviewed by 
Shuttle operations personnel is that one must understand how to properly define, selecf and infegrafe 
COTS/MOTS componenfs. Policies governing COTS and fasfer-beffer-cheaper approaches musf be 
defined fo permit clear and consistent application and to mitigate risk to budget and schedule [27-35]. 

Trade studies of COTS producfs involving "musf meef," "highly desirable," and "nice fo have" 
requiremenfs will help defermine whaf producf fo choose, whaf requiremenfs if musf meef, and if a 
cusfom approach should be faken insfead. Any addifion fo or relaxafion of requiremenfs musf be 
idenfified. A need for new requirements may not become visible until testing and implementation of fhe 
producf is underway. The impacf of COTS driven hardware and soffware changes fo an infegrafed 
sysfem musf be assessed. 

COTS/ MOTS Policy 

A policy is needed to help prevent cost, schedule and technical difficulties from imperiling projecfs thaf 
use off-fhe-shelf ifems [27-37]. Criferia for defermining whefher a COTS approach can be faken musf be 
defermined. Of prime imporfance is defining fhe level of insighf needed info vendor soffware, soffware 
mainfenance and cerfificafion processes. Problems in COTS projecfs can arise when requiremenfs are 
levied on fhe producf fhaf fhe vendor did nof originally infend for fhe unif fo meef. Using COTS may 
mean eifher compromising requiremenfs on fhe COTS unif or on fhe infegrafed sysfem. Whefher or not 
new requirements have to be applied to the unit is a critical decision. Unfortunately, new requirements 
may not be recognized until the COTS product experiences difficulties in the testing and integration 
phases of fhe projecf. 

The Shuffle Program creafed COTS/MOTS soffware guidelines for varying levels of applicafion crificalify. 
This recommended policy defines whaf considerafions should be made before deciding fo procure a 
COTS/MOTS producf. The following should be examined based on fhe crificalify (impacf of failure on 
safefy of flighf or mission success) of fhe applicafion and producf in quesfion [38]. 

Certification Plan — How much of fhe vendors in-house cerfificafion can be relied upon? For crifical 
applicafions, addifional fesfing will be needed if access fo fesf resulfs, source code and requiremenfs 
documenfs is nof allowed. Can fhe unif be cerfified fo a level commensurafe wifh fhe crificalify of the 
application? 


26 of 118 



Vendor Support — This should cover the certification process and the system life cycle. The level of 
supporf should be defined based on fhe crificalify of fhe sysfem. Vendor supporf required for fesfing, 
infegrafion, and mainfenance over fhe life cycle of fhe producf musf be defined. If whife box fesfing 
(rafher fhan black box fesfing) musf be performed, design insighf from fhe vendor will be required and 
propriefary agreemenfs must be negotiated. The vendor may possess information on problems other 
users have encountered, which will be useful during infegrafion and over fhe life cycle of fhe producf. 
An addifional risk in using "off-fhe-shelf" unifs concerns fhe availability of fhe vendor. Can a user 
confinue fo use and mainfain a producf if fhe vendor goes ouf of business or stops producing and 
supporting fhe producf? 

Product Reliability — Vendor developmenf and certification processes for bofh hardware and soffware 
should be examined. 

Trade Studies — Trade sfudies and risk idenfificafion musf be performed before commitfing fo fhe use of a 
parficular unif and infegrafion archifecfure. Define "musf meef," "highly desirable" and "nice fo have" 
requiremenfs. Ability of fhe unif fo meef fhose requiremenfs, and af whaf cosf, will be a major deciding 
facfor in the COTS decision. Identify loss of operafional and upgrade flexibility as well technical risks 
and cost associated with the product. Examine the impact of fhe producf on fhe infegrafed system, 
including hardware and software interface changes. Compare fhe proposed COTS producfs fo a cusfom 
developed producf. Assess life expecfancy of fhe producf and if's frack record in fhe markef place. 

Risk Mitigation — Identify areas fhaf increase risk, such as lack of supporf if fhe vendor goes ouf of 
business or fhe producf is no longer produced. Ensuring vendor supporf over fhe producf life cycle can 
mitigate risk, along wifh gaining access fo source code, design requiremenfs, verification plans and fesf 
resulfs. Off-line simulations of fhe producf should also be considered. Can access be obtained to vendor 
information on product issues discovered by other users? 

I mpact Of COTS Disappointments 

The success of inexpensive and easily available GPS technology has led some to believe that applying 
GPS technology is relatively straightforward, wifh low risk and low cosf. Nof undersfanding fhe 
complexify of GPS fechnology will lead fo unrealistic budgef, schedule, and fechnical success 
expecfafions. Assuming fhaf "cheap and easy" ferresfrial GPS means applying such fechnology fo 
spacecraff will be "cheap and easy" has prevented fhe mafurafion of GPS unifs for use on spacecraff [11]. 

New fechnology projecfs may encounfer significanf fechnical problems, budgef overruns and schedule 
slips due fo unrealistic expecfafions fhat defined projecf budgef and schedule. These experiences may 
cause both engineers and managers to become suspicious of the technology in question. The political and 
budgetary climate may demand a COTS solution, but problems using a certain technology can lead to 
reluctance to work with that technology in the future, particularly in a COTS project. The problem is not 
with the technology but with the unrealistic expectations that were attached to the new or off-the-shelf 
fechnology. These unrealistic expecfafions arise from a failure fo appropriafely investigate and plan for 
fhe use of a COTS producf when defining schedule, budgef, and requiremenfs. These expecfafions are 
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based on a lack of understanding about the original design and application of the product in question. 
COTS products are "proven" devices only when used in the applications for which they were originally 
designed. The vendors met the contractual obligations of the original customer. The issue is not the 
technology, or the use of a COTS product, but rather how that technology was applied to meet the needs 
of the original customer. 


Take Advantage Of Lessons Learned 

When performing trade studies and risk assessments, previous users of the technology should be 
consulted. Independent consultants who have worked with a variety of units in different programs and 
who do not have a stake in the choice of a particular unit are a good source of information. Users and 
consultants may possess valuable knowledge based on hands-on experience that may not be available 
from a vendor. Consultants and other users can also provide valuable insight into the rationale and 
requirements that governed the original design of the unit. Taking advantage of such information 
enhances identification of cost, schedule and technical risks, and can help an integrator and user 
formulate more robust requirements. 

Starting in the mid 1990s, Shuttle operations persormel working on GPS began reviewing reports from 
accident investigations and spacecraft failures. A number of reports have been published highlighting 
the challenges of software development and analyzing failures of unmarmed spacecraft, some of which 
used COTS and a "faster-better-cheaper" approach [27, 37, 39-50]. Some issues identified by those 
reports are listed in Table 2. 


Do Not Take Shortcuts With Process 

Process entails requirements definition, development of software, manufacture of hardware, verification, 
validation, integration, testing (at both the component and system level), data analysis, issue resolution, 
and certification by regulatory agencies. Problems in process can manifest as technical issues at the 
component or system level, user issues due to lack of understanding proper receiver or integrated system 
operation, schedule slips and cost overruns. Was the spurious active television anterma output that 
caused the recent GPS interference incident in Galifomia [8] the result of a process problem with design 
or manufacture? Process problems can delay the fielding of augmentation and improved constellation 
ground support systems that are needed to enhance navigation capabilities, and ensure integrity [51]. 

It is difficult to assess the quality of software requirements and code development processes when they 
are of a proprietary nature. Most software is not written from scratch, but is reused and modified for 
new applications. Development of legacy code may not have adhered to coding standards as it evolved, 
or been subjected to a robust process (requirements definition, code reviews, configuration management 
of code and supporting documentation, unit testing, lab testing of the receiver and integrated system, 
testing in the operational environment). Processes should be designed to focus resources on areas where 
the root cause of problems are frequently found. For example, many root causes of software issues occur 
during requirements definition and at hardware/software interfaces [52]. 
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Table 2 - Lessons From Other Programs 


• Technical risks not identified and managed. 

• Software development process not well 
defined, documented or understood. 

• Contract consolidation led to corporate 
knowledge loss concerning critical systems. 

• Lack of independent verification and 
validation. 

• Inadequate communication between project 
participants. 

• Lack of management involvement and 
oversight. 

• Inadequate spacecraft monitoring and 
procedural errors by operators. 

• Navigation equipment not well understood. 


• Spacecraft operators not familiar with 
system design, operation and failure modes. 

• Lack of a formal, disciplined process for 
documenting, advertising and resolving 
issues. 

• Inadequate staffing and training. 

• Legitimate issues ignored and attributed to 
resistance to a "new way" of doing business. 

• Frequent turnover of management and 
technical personnel. 

• Issues ignored due to cost and schedule 
pressure. 

• Roles and responsibilities not defined. 


The requirements definition, verification and validation processes require special attention [53]. Most 
software problems can be traced back to flaws in specifying requiremenfs, nof fo coding errors [9, 54]. 

Flaws in requiremenfs specificafion resulf from incorrecf assumptions about system operation or 
unanticipated aspects of fhe operating environmenf. Requiremenfs should also specify how a componenf 
or sysfem should acf under off-nominal conditions. 

Proper documenfafion of requiremenfs, and requiremenfs rationale, is imporfanf. Much soffware in use 
today is mainfained by personnel who did nof parficipafe in fhe original developmenf of fhe 
requiremenfs and code [52]. Lack of documenfafion and corporafe knowledge loss can pose fechnical, 
cosf and schedule risk to projects that reuse existing software [55]. 

A review [9] of seven recent aerospace accidents identified sixfeen common facfors: 1) overconfidence 
and over reliance in digifal automation; 2) nof undersfanding fhe risks associated wifh soffware; 3) 
confusing reliabilify and safety; 4) over relying on redundancy; 5) assuming that risk decreases over time; 

6) ignoring early warning signs; 7) inadequate cognitive engineering; 8) inadequate specifications; 9) 
flawed review process; 10) inadequate safety engineering; 11) violation of basic satefy engineering 
pracfices in fhe digifal parfs of fhe sysfem; 12) soffware reuse wifhouf appropriafe safefy analysis; 13) 
unnecessary complexify and soffware funcfions; 14) operational personnel nof undersfanding 
automafion; 15) fesf and simulation environmenfs fhaf do nof match the original environment; and 16) 
deficiencies in safefy-relafed information collecfion and use. Many of fhese facfors may be classified as 
problems wifh fhe processes used fo develop, integrate and use devices and systems fhaf confain 
soffware, which includes GNSS receivers and associated supporf systems. 

John L. Goodman, Knowledge Capture and Management for Space Flight Systems, NASA Contractor Report 
CR-2005-213692, October 2005. Available at http://ntrs.nasa.gov/ 
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However, robust processes can be expensive [52]. A rigorous and successful process, such as that used 
for the Space Shuttle flight software, may not be economically viable for a vendor. Controversy over cost 
has surrounded the Federal Aviation Administration's DO-178B standards for avionics certification. 
Hiring and retaining skilled personnel to support these processes is challenging. 

Use of new or off-the-shelf technology has the potential to lower development, integration, and life cycle 
costs. However, successful use of a technology in other applications and environments does not mean 
that applying the technology in a new application or environment will be straightforward and low cost. 
Trade shows, conferences and industry magazines often do not highlight the technical and management 
challenges encountered when applying a new technology. The temptation to cut costs by cutting corners 
during requirements formulation [56], product or technology selection, development, integration, testing 
and certification should be avoided. False and simplistic perceptions of the maturity or flexibility of a 
technology can result in flawed processes that will increase technical, cost and schedule risk. Well- 
defined processes, clear lines of technical and management authority, accountability, and specific goals 
are required. Technical and management issues must be meticulously documented in a manner that 
provides visibility throughout the project. Clear lines of communication are essential to enable project 
members at both the organizational and individual levels to facilitate issue resolution. 

Technical issues must be addressed early in a project, even in the presence of cost and schedule concerns. 
These issues can easily become show-stoppers later in the integration. Not addressing issues until late in 
a project will drive up cost and shift schedules to the right. Problems arising from cost and schedule slips 
and failure to address issues can create adversarial relationships between project participants and the 
vendor. 

The data path from the receiver to the user needs to be completely and clearly defined. This includes on¬ 
board and ground hardware and software, and associated requirements documents. System 
requirements owners should also be clearly identified. New users of GPS data may experience difficulty 
in elevating concerns through unfamiliar and complicated software and hardware configuration control 
processes than encompass multiple spacecraft and ground systems. 


Lab And Flight Testing 

A number of spacecraft failures have resulted from a lack of comprehensive, end-to-end testing [9, 57]. A 
limited amount of flight and ground testing to ensure that the unit meets specifications may not exercise 
enough of the software to uncover software issues. If the new application is different from that for which 
the product was designed, and modifications have been made, the amount and scope of testing will have 
to go beyond that needed to verify that the unit meets contract specifications. Both off-line and 
integrated testing of interface software in units that interact with the COTS product are required. 


The ISS, X-38, and Shuttle GPS projects illustrated the need for thorough ground and flight-testing. The 
level of testing required varies with the criticality of the application. Sufficient resources and schedule 
should be provided to permit the appropriate level of testing to be conducted early enough in a program 
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to catch performance issues so that they may be resolved in a timely manner. If if can be afforded, 
exfensive fesfing of fhe complefe sysfem and provision for inferim soffware versions is highly desirable. 

Shuttle GPS - A Safety-Critical Application 

The Shuffle GPS receivers are required for hypersonic, supersonic and subsonic flighf and landing of an 
-100 fon glider. As such, receiver and overall avionics performance are safefy crifical and musf be highly 
reliable. The Shuffle fesf program permitted exfensive ground fesfing of fhe MAGR/S in a sfand-alone 
configurafion wifh a signal generator, and integrated wifh a ground duplicate of fhe Shuffle avionics 
sysfem. Mulfiple fly/fix/fly cycles of inferim GPS receiver soffware versions were performed. 
Modificafions of Shuffle flighf compufer soffware inferfacing wifh fhe receiver were also idenfified and 
proven in ground fesfing and Shuffle flighfs (Table 1, page 21) before MAGR/S cerfificafion. 

The Shuffle/GPS infegrafion archifecfure allowed a single GPS receiver to be flown for dafa collecfion 
while fhe baseline, cerfified legacy Shuffle navigafion sysfem operafed. Shuffle soffware fhaf inferfaced 
wifh and processed MAGR/S dafa was exercised in flighf. This infegrafion archifecfure permitted flighf 
evaluafion of all hardware and soffware componenfs of fhe GPS infegrafion wifhouf requiring fhe use of 
GPS for Shuffle navigafion. 

ISS GPS - A Non-Safety Critical Application 

A non-safety critical application may not warrant the same level of fesfing as a safefy-crifical applicafion. 
The ISS GPS receivers, whose dafa supporf antenna poinfing, fime deferminafion and provide sfafe 
vecfors to various users on fhe ISS, are nof safefy-crifical. There are ofher mefhods of sfafe deferminafion 
available, such as GPS/GLONASS receivers on fhe Russian segmenf of fhe ISS, Russian ground fracking, 
and U.S. ground fracking. However, significanf mission impacfs can occur due to malfuncfions of GPS 
receivers. While fhese impacfs may nof always fhreafen safefy of flighf, fhey may increase operafions 
cosfs, drive exfensive anomaly invesfigafion and soffware changes, and prevenf fhe accomplishmenf of 
science and mission objecfives. However, dysfuncfional inferacfion befween a non-safety critical GPS 
receiver and safety-critical elements of an avionics sysfem could pose a safefy risk. Even for non-safety 
applications, an appropriate level of GPS and overall sysfem fesfing musf be determined fo avoid fhreafs 
to cosf, schedule, and fhe achievemenf of mission objecfives. 

The Difficulty of GPS Testing 

GPS receivers frack and download dafa from mulfiple satellites. Signal sfrengfh, antenna obscurafion, 
radio-frequency inferference, and mulfipafh can all effecf fhe ability of a receiver fo successfully perform 
acquisifion, fracking, measuremenf processing, and dafa collecfion fasks. Soffware pafhs executed wifhin 
GPS receivers are highly influenced by fhe radio-frequency environmenf. Tesf flighfs in fhe flighf 
environmenf, as was accomplished wifh MAGR/S flighfs on Shuffle missions (Table 1, page 21), are fhe 
besf way fo fesf a receiver. Due fo fhe infegrafion archifecfure, fhese flighfs also exercised fhe same 
Shuffle compufer soffware (GPS qualify checks, felemefry, commanding, receiver aiding dafa, efc.) fhaf 
would be supporfing acfual use of GPS after cerfificafion and TAGAN replacemenf. However, fhis is 
expensive and may nof be feasible in many applicafions. 
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Tests of the ISS and CRV SIGI units on the Shuttle (Table 1, page 21) were valuable, but they could not 
subject the SIGI units to the exact radio-frequency environment later encountered on the ISS. Nor were 
Shuttle flight tests of ISS SIGI able to exercise the complete GPS data path from the SIGI, through the ISS 
avionics and telemetry system, to the users in Mission Gontrol. The first time ISS SPOT developers noted 
telemetry issues with SIGI data was after the SIGIs were operational on the ISS. GPS receivers may 
manifest performance problems after extended, continuous use (weeks or months) that may not manifest 
on shorter test flights. Some of the issues with the ISS SIGI unit could not have been caught during 
laboratory or Shuttle flight tests. While a non-safety critical application such as ISS GPS may not warrant 
the extensive test program that the safety-critical Shuttle MAGR/S was subjected to, there is risk of late 
discovery of performance issues that pose a risk to cost and schedule. 

Lab Testing 

Lab testing of GPS receivers is important for verifying data interfaces, commanding, basic functionality, 
receiver performance under dispersed trajectory conditions, and the ability of the receiver to operate in 
an integrated system. While GPS signal generators are useful for subjecting receiver software to flight 
dynamics, they cannot replicate the radio-frequency environment encountered in flight. Testing using 
roof-top antennas can also be useful, but cannot duplicate the flight dynamic or radio-frequency 
environments. Testing must not be limited to basic tests to ensure that the unit meets published accuracy 
and availability specifications. Extensive testing of both the receiver and interfacing host vehicle 
software using both nominal and off-nominal inputs should be conducted. Receiver anomalies will 
appear in flight tests that may not manifest during lab testing [17, 58]. Gonversely, some anomalies 
found during lab testing may not occur in flight. 

Gommand and data collection interfaces should be exhaustively examined in lab testing prior to more 
expensive test flights. This will help ensure that interface and data collection problems do not occur 
which could make it impossible to verify receiver performance during a flight. Software issues that do 
not manifest in aviation applications due to a flight time of minutes or hours can manifest during a much 
longer space flight. For space applications, lab tests lasting many days or weeks should be conducted. 

Many software issues could have been found earlier in the Shuttle GPS project had a more thorough 
ground test program been conducted. A limited number of lab and flight tests to ensure that the box 
"meets spec" will not exercise enough of the software to find issues. This is particularly important for 
safety of flight applications. Vendors tend to perform the minimum amount of lab testing needed to 
ensure that the unit meets contract specifications. Vendors may not consider flight testing to be valid if 
they do not trust the source of truth vectors. 

Testing should also involve any hardware and software that interfaces with the unit. Thorough off-line 
testing of the unit and proposed algorithms that will interface with it should be performed before 
committing to specific integration architecture. Once the integration has been performed, thorough 
testing of navigation unit interaction with the rest of the avionics system is needed. 
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Early testing of the X-38 SIGI and knowledge of CRV frajecfory requiremenfs enabled fhe cold sfarf 
affifude deferminafion issue fo be caughf early, providing fime fo analyze fhe issue and develop an 
alfernafe procedure using digifal video cameras (see Chapfer 10, page 93). 

Allocate Sufficient Resources And Schedule For Testing 

Soffware issues fend fo be discovered sequenfially. Unifs confaining complex soffware may nof manifesf 
anomalies in fhe inifial round of ground and flighf fesfs. This can lead fo a false sense of securify abouf 
fhe mafurify of a soffware version. Enough rigorous ground and flighf fesfing musf be planned fo 
fhoroughly exercise fhe soffware. Schedule and budgef should include inferim soffware versions fo 
allow issues fo be discovered and resolved before a producfion soffware load is scheduled for 
cerfificafion. A lack of comprehensive, end-fo-end fesfing has resulfed in a number of spacecraff failures 
[9,57]. 

Adequafe fime and personnel musf be sef aside fo analyze flighf and ground fesf dafa. If dafa is nof 
fhoroughly analyzed in a fimely manner, soffware issues will go unnoficed. Lack of resources can even 
lead fo failure fo analyze fesf dafa. Performance issues arising lafe in fhe developmenf and cerfificafion 
cycle can negafively impacf cosf and schedule. 

Produce, Test and Fly I nterim Software Versions 

GPS receivers fend fo become more robusf affer use in mulfiple applicafions has allowed users fo idenfify 
and fix soffware anomalies. Some anomalies may nof be fixed, as a previous user has judged fhem fo be 
of no impacf fo fhe applicafion in quesfion. However, fhese issues may be an impacf fo a subsequenf user 
of fhe same device. Infroducfion of a GPS receiver info a new operafing environmenf (such as going 
from an aircraff fo a spacecraff, or from a low Earfh orbif applicafion fo a higher orbifal alfifude) can lead 
fo manifesfafion of soffware issues nof seen before. Differences in flighf durafion (aviafion versus orbif, 
hours versus days or weeks) can also defermine which soffware issues will manifesf. For orbifal 
applicafions, lab fesfs fhaf subjecf a receiver fo orbifal dynamics for days or weeks should be considered. 

Inferim soffware versions and mulfiple fly/fix/fly cycles (Table 1, page 21) were insfrumenfal in resolving 
Shuffle MAGR/S performance and Shuffle flighf compufer issues, and builf confidence in fhe sysfem 
prior fo cerfificafion for operafional use in a safety critical application. From September 1996 to February 
2003, over 7,000 hours of "nominal performance" MAGR/S operafing fime was accumulafed during 
Shuffle missions. The parallel infegrafion archifecfure enabled fhe receiver fo be flown in fhe acfual 
dynamic and radio-frequency flighf environmenf in a fesf mode, while inferfaced wifh Shuffle flighf 
compufers [1]. 

I nstrumentation Port Data I s Needed During Flight and Ground Tests 

Insfrumenfafion porf dafa provides invaluable insighf info soffware behavior during periods of 
questionable performance. Vendor inpuf should be solicifed concerning whaf dafa fo collecf and how if 
should be inferprefed. Insfrumenfafion porf dafa simplifies and speeds up fhe idenfificafion of soffware 
problems. Soffware on dafa collecfion plafforms (such as laptop compufers) musf be fully tested. 
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documented and certified. Clear and accurate procedures for laptop operation and troubleshooting are 
needed. Otherwise, it may be difficult to distinguish GPS receiver problems from problems wifh fhe dafa 
collecfion compufer. Lack of insfrumenfafion porf dafa will lengfhen fhe fime needed fo resolve a 
soffware anomaly, and may even prevenf ifs resolufion. Due fo fhe June 1998 GPS receiver and Shuffle 
soffware anomalies on STS-91, a lapfop compufer was flown on many subsequenf missions fo collecf 
insfrumenfafion porf dafa. 

Conduct Enough Test Flights Before Making Critical Decisions 

Initial flights of fhe 3M receiver (pre-producfion MAGR, Table 1, page 21, see also Chapfer 7, page 57) 
were very successful. Lafer flighfs of fhe MAGR/S, along wifh ground fesfing and soffware audifs, 
uncovered many issues fhaf had fo be resolved before fhe MAGR/S could be cerfified for TACAN 
replacemenf. If is imporfanf nof fo be lulled info fhinking problems are nof ouf fhere based on a small 
number of inifial, successful fest flighfs. Numerous soffware issues were discovered during fhe STS-91 
flighf in June of 1998, resulfing in a fhree-year delay of MAGR/S cerfificafion for operafional use. 
However, fhe fhree TACAN unifs had already been removed from fhe orbifer Atlantis and fhree MAGR/S 
had been installed. The Shuttle Program had to remove three string MAGR/S and reinstall three string 
TACAN in Atlantis. 

Maintain Configuration Control Over Test Equipment And Procedures 

Perceived anomalous navigation unit performance in fhe lab is more likely fo be caused by improper fesf 
equipmenf configurafion and improper procedures, rafher fhan soffware or hardware problems in fhe 
receiver, signal generafor, or GPS safellife problems. A lack of accurafe, documenfed fesf procedures can 
make if difficult to duplicate questionable receiver performance in lafer fesfs. This lengfhens fhe amounf 
of fime if fakes fo defermine fhe cause of suspecf behavior. When frying fo diagnose quesfionable 
performance, an accurafe record of whaf procedures were performed and fhe fesf equipmenf hardware 
and soffware configurafion is invaluable. Soffware associafed wifh lab simulafions and dafa collecfion 
for bofh lab and flighf fesf applicafions should be accurafely documenfed and verified. A lack of 
laboratory configurafion confrol and documented operating procedures can result in a failure fo discern 
fhe difference between a unit problem, a test equipment problem, or a user error. 


Provide The Vendor With As Much Data As Possible 

Vendors often complain that users provide minimal data when a problem with a unit occurs. Devices 
containing software are complex computers whose performance depends on a variefy of facfors. For 
example, in fhe case of GPS, a plof illusfrafing quesfionable posifion and velocity performance is nof 
enough fo permif a vendor fo diagnose fhe frue cause of an alleged anomaly. The vendor should be 
provided wifh as much digital data as possible, particularly channel and tracking parameters. 
Information on antenna location, hardware configuration and the procedures that were executed is also 
helpful. Vendors are busy and receive large numbers of inquiries from fhe user community. Users who 
suspect that a unit is malfunctioning should make a thorough investigation to determine if fhe alleged 
performance is a user error before involving fhe vendor. 
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I ntegrated Teams 


Communicate Early, Communicate Often 

Participation by experienced personnel from various disciplines who possess sharp technical skills and 
are motivated by lessons learned from pasf projecfs can facilifafe developmenf of robusf and realistic 
requiremenfs, and enable issues fo be nofed early in fhe projecf. Open and unresfricfed communication 
befween all projecf parficipanfs (vendor, users, infegrafors, hosf vehicle sysfems specialisfs) is essential fo 
ensure fhaf robusf and accurafe requiremenfs are developed, issues are nofed, and issues are resolved in 
a timely fashion. Open communication creafes a positive working environmenf and enables feam 
members fo become educafed on issues raised by various parties. 

The success of fhe Mercury, Gemini, Apollo, Space Shuffle, and ISS spacecraff developmenf and flighf 
programs was in parf due fo fhe exisfence of infegrafed feams, which freely communicafed across 
corporafe and civil servanf/confracfor boundaries. All parficipanfs had access fo requiremenfs and 
source code for a variety of on-board and ground sysfems, leading fo a good undersfanding of sysfem 
requiremenfs and fechnical difficulfies. This access facilifafed accurafe communication and timely issue 
resolution. Furfhermore, fhe Mercury, Gemini and Apollo spacecraff were nof nearly as complex as fhe 
Space Shuffle, ISS (and fufure vehicles), and required a smaller number of specialisfs fo design, fesf and 
undersfand fhe sysfems. The increasing complexify of aerospace vehicles requires more specialisfs fo 
assess fhe impacfs of fechnical issues and modifications, which in fum necessifafes effecfive and accurafe 
communicafion. However, an environmenf of effecfive communication can be difticulf fo mainfain over 
fhe long ferm in a large program, as evidenced by fhe losses of Challenger and Columbia [59-61]. All four 
NASA JSG GPS projecfs demonsfrafed fhe need for a close working relationship befween fhe infegrafion, 
user, and vendor personnel. 

The success-orienfed nafure of projecf budgefs and schedules sometimes resfricfs communicafion af fhe 
fechnical level. Little or no money will be saved by a success-orienfed approach fhaf limifs 
communicafion in an affempf fo save money. Multiple layers of confracfors cuf down on communicafion 
and should be avoided. Goncern abouf keeping managemenf and fechnical discussions wifhin fhe scope 
of fhe confracf are valid, buf such concern should nof resfricf open discussion of issues fhaf are wifhin fhe 
scope of fhe confracf. Frequenf and open communicafion befween personnel (fechnical and 
managemenf) is fhe key fo cafching and resolving problems early, lowering risk fo cosf and schedule, and 
building positive working relationships among feam members. Trying fo obfain design informafion in 
fhe presence of firewalls wasfes time and money. Knowledge of producf design and operation should 
nof be isolafed fo a selecf few. Infegrafion engineers musf have access fo fesfing facilities and dafa so fhey 
can become familiar wifh box performance. 

Early MAGR/S projecf reviews focused on hardware modifications, wifh little attention paid fo software. 
Mosf fechnical personnel were "fire walled" from fhe software missionizafion process and fhe vendor. 
No formal, program wide reviews of fhe GPS receiver software modifications were made. The GPS 
vendor and fhe Shuffle navigation (bofh operational and engineering, confracfor and civil servanf) 
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personnel had minimal involvement in the missionization decisions made by the integrator. As a result 
of the GPS receiver and Shuttle flight computer anomalies that surfaced during STS-91, fhe GPS vendor 
was more fully infegrafed info fhe GPS projecf fo enhance communicafion. Weekly feleconferences were 
esfablished fhaf included fhe vendor and all NASA and confracfor organizafions. Face fo face meefings 
of all projecf parficipanfs were held af fhe Johnson Space Genfer fhree fo four fimes a year. Special feams 
fhaf crossed civil servanf and confracfor boundaries were formed fo address specific fechnical and projecf 
managemenf challenges. 

The Role of the User 

Users of fhe GPS receiver should be infegrafed info fhe projecf from fhe sfarf, and work alongside 
development infegrafion, and vendor personnel. The user brings an operafional and procedural 
perspecfive fo fhe projecf. User inpuf info fhe requiremenfs process may prevenf fechnical and 
procedural issues from arising affer fhe operafions phase has begun. Such issues may drive complicafed 
and fime-consuming work-arounds, analysis, and new soffware developmenf. Receiver and sysfems 
requiremenfs fhaf reflecf user considerafions are a key fo reducing life cycle cosfs once fhe operafions 
phase has begun. 

Personnel from fhe JSG Missions Operafions Direcforafe (MOD), responsible for Mission Gonfrol 
acfivifies, mission design and planning, procedure and flighf rules developmenf, and asfronauf framing, 
were closely involved in fhe MAGR/S infegrafion efforf. MOD personnel parficipafed in evaluafion of 
MAGR/S flighf fesf dafa, developmenf of performance requiremenfs, developmenf of soffware and crew 
display requiremenfs, anomaly invesfigafion and anomaly resolution. User involvemenf fhroughouf fhe 
MAGR/S projecf was lafer credifed as a factor in fhe projecf success, in spite of numerous fechnical 
challenges. Early user involvemenf in fhe MAGR/S projecf was also a facfor in fhe success of fhe lafer 
Shuffle SPOT projecf. 

Vendor I nvolvement 

Use of soffware intensive producfs in high-visibilify, high-risk, and safefy-relafed applications requires a 
higher level of vendor parficipafion fhan ofher applicafions. Unforfunafely, many vendors have little or 
no insighf info how fheir producfs are infegrafed and used. Due fo communicafion consfrainfs imposed 
by success orienfed budgefs and schedules, vendors are frequenfly nof involved in fhe definition of 
infegrafion and soffware requiremenfs. The "fhrow a unif and an Inferface Gonfrol Documenf over fhe 
fence" approach can lead fo cosf and schedule problems. Vendor parficipafion fhroughouf fhe 
infegrafion, fesf and cerfificafion program is invaluable, particularly if fhe receiver is used in an 
applicafion for which if was nof originally designed. The vendor possesses insighf info receiver 
operation and design fhaf is useful fhroughouf a projecf. Vendor assisfance in hosf vehicle sysfems and 
fesf requiremenfs definition, receiver and infegrafed sysfem anomaly resolution, procedure developmenf, 
and dafa analysis can reduce risk fo cosf and schedule over fhe life of a projecf. Vendor supporf is more 
eftecfive if fhey are provided wifh as much dafa as possible, along wifh fesf and flighf equipmenf 
configurafions and procedures fhaf were execufed. Vendor personnel should be given opporfunifies fo 
learn abouf fhe applicafion, as if may be differenf from previous applicafions of fhe receiver. This 
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knowledge may be useful in avoiding surprises due to use of a receiver in an application that it was not 
originally required to operate in. Fixed price contracts may limit or even prevent vendor participation. 
Such contracts pose high risk to cost and schedule. If the receiver vendor is a subcontractor to a 
navigation unit integrator, contracts should be written and budget provided to ensure that the vendor is 
accessible. 

What the Vendor Brings to the Table — Vendors possess valuable insight into a product through their 
knowledge of the product; it's original design requirements, and experience from previous applications 
of the technology. The vendor can be invaluable in reducing technical, cost and schedule risk by 
providing assistance in areas such as addressing anomalies, resolving questions over technology 
application, defining requirements (software, hardware, testing, integration). Technical interchange 
between both the vendor and user is required for risk mitigation. Early vendor participation in 
discussions on integration and architecture should be sought. The vendor can provide sage advice based 
on a detailed knowledge of unit operation. The vendor may also identify concerns related to the use of 
the product in a new environment. New (i.e. the product was not originally designed for the 
application), high risk, high visibility and safety critical integrations require more vendor involvement 
than other projects. 

Budget for Access to the Vendor — The GPS receiver is a critical part of the SIGI. Unfortunately, due to cost 
and schedule concerns, the user and SIGI manufacturer often had little or no opportunity to interact with 
the GPS vendors in the Shuttle, ISS and GRV SIGI projects. This made identification and resolution of 
GPS performance issues difficult. Gontracts concerning integrated units should be written so that 
vendors of critical, software intensive components can be involved and able to give advice and 
information to the unit manufacturer, the integrator and the user. 

The Vendor and the Shuttle GPS Project — In hindsight, some aspects of the Shuttle GPS integration might 
have been done differently had the vendor been involved earlier in the project. The Shuttle software that 
interfaced with the MAGR/S was designed with an inadequate understanding of the software behind the 
interface definition. This lack of receiver insight was one of the causes of the problems encountered on 
STS-91. Initially, contact with the MAGR/S vendor was limited to a small group of personnel. 
Information obtained from the vendor was not passed on to other project participants, and the vendor 
was not consulted enough on integration and performance issues. After STS-91 the MAGR/S vendor was 
fully integrated into the GPS project team. Regular face-to-face contact between the vendor and Shuttle 
engineers built positive personal relationships and established a team rather than an adversarial 
environment. Both the vendor and Shuttle Program engineers became familiar with each other's work 
cultures, which enabled them to work better together and provide appropriate support to each other. 
Interaction with project participants during weekly teleconferences and face-to-face meetings enabled the 
vendor to understand concerns and various points of view expressed by project members, enabling them 
to propose solutions that were agreeable to all parties. The vendor also provided much needed 
education to Shuttle engineers concerning the challenges of GPS receiver design and operation. 
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Enable The Vendor to Learn About Your Application — While vendors have valuable knowledge about unit 
design, operation and performance in various applications, they may not fully undersfand fhe 
implicafions of using fheir producf in a new environment. Vendor understanding of fhe new applicafion 
environmenf and user requiremenfs is necessary fo enable fhe vendor fo supply fhe besf possible supporf. 
In fhe case of fhe Shuffle GPS projecf, vendor inferacfion wifh Shuffle personnel enabled fhem fo 
ascerfain how fhe Space Shuffle applicafion differed from aviafion users of fheir producf. Observing 
Shuffle ascenf and enfry from Mission Confrol, flying landings in a Shuffle simulafor, and parficipafing in 
MAGR/S fesfing af Space Shuffle Program facilifies enabled fhe vendor fo become familiar with the 
Shuttle flight regime, crew and Mission Gontrol procedures, flight rules, and aspects of Shuffle mission 
design. This facilifafed better undersfanding of cusfomer concerns and helped fhem identify 
improvemenfs fo be made fo fhe receiver. The vendor provided advice fhaf improved ground and flighf- 
fesfing, issue identification, and issue resolution. The vendor also became familiar wifh fhe sfrengfhs and 
weaknesses of Shuffle Program GPS simulation facilifies. This enabled fhem fo provide inpuf fo Shuffle 
infegrafion engineers concerning how besf fo perform receiver fesfing and verify functionality. 


The Challenge Of Being A New User 

In the mid 1990s, telemetry constraints and a complex ISS software requirements process prevented 
orbital debris avoidance needs from being addressed in ISS GPS felemefry requiremenfs definition. The 
ISS SPOT applicafion was nof conceived for several more years. Likewise, fhe use of MAGR/S dafa for 
fhe Shuffle SPOT applicafion was nof idenfified unfil about three years after flights of fhe MAGR/S and 
associafed Shuffle compufer software had begun. However, fhe developmenf and fesfing of fhe Shuffle 
SPOT applicafion encounfered far fewer fechnical difficulfies fhan fhe ISS SPOT applicafion. This was 
due fo fhe differences befween fhe development and test phases of the two projects. 

The safety-critical MAGR/S project enjoyed extensive, full sysfem fesfing in bofh laborafories and fhe 
flighf environmenf. Associafed Shuffle software and felemefry requiremenfs were exhaustively reviewed 
by all projecf parficipanfs (civil servanf and confracfor, engineering personnel. Mission Gonfrol and 
mission design personnel) before fhe inifiafion of MAGR/S fesf flights on the Shuttle. Furthermore, SPOT 
processing of MAGR/S dafa for developmenf purposes did nof begin unfil several inferim receiver 
software versions had been produced and fesf flown. Vendor involvemenf ensured fhaf projecf 
participanfs undersfood MAGR/S dafa and operafing characferisfics. MAGR/S software, originally 
developed af government expense, had been made available to the Shuttle Program and was undergoing 
an audit by the NASA IV&V contractor. This also ensured that receiver performance and operafion was 
well undersfood. While fhe MAGR/S was nof ready for cerfificafion fo supporf Shuffle TAGAN 
replacemenf, it had undergone enough testing to avoid major technical surprises during the Shuttle SPOT 
development process. 

New uses for GPS receiver dafa will mosf likely be idenfified fhaf were nof anficipafed when fhe initial 
spacecraft GPS and overall sysfem requiremenfs were wriffen. Requirements for componenfs in fhe 
infegrafed sysfem (GPS receivers, inferfacing on-board avionics, on-board and ground felemefry 
processing) may nof meef fhe needs of fhe new user. Furfhermore, sysfems infegrafors, software process 


38 of 118 



owners and operations personnel may not initially recognize the new user as a customer for the data. 
This may make it difficult to get priority and support for resolving issues, idenfifying requiremenfs and 
soffware changes, and getting changes approved and implemenfed. While if is nof possible fo forecasf 
wifh 100% accuracy whaf new uses for receiver dafa on a particular spacecraft may come up in the future, 
experienced personnel should make an effort to identify oufpuf dafa and felemefry requiremenfs fhaf will 
avoid problems experienced wifh pasf infegrafions. New users of GPS dafa may experience difficulty in 
elevating concerns through unfamiliar, poorly defined, and/or complicafed soffware and hardware 
configurafion control processes that encompass multiple on-board and ground systems. 


Documentation 

A lack of configurafion-confrolled documenfafion can lead fo incorrecf knowledge abouf receiver or 
signal generator design, operation and performance. Inadequate understanding of unif design and 
operation can also lead fo misinferprefafion of fest resulfs. This makes problem resolution more 
expensive. A lack of accurate, defailed producf documenfafion forces infegrafors fo spend significanf 
amounfs of lab time frying fo gef fhe unif fo work properly. Frequenf consulfafions wifh fhe vendor 
drives up projecf cosfs. 

Keep Accurate Records 

Detailed and accurate records of meetings, issues and issue disposition, design rafionale, and fesfing 
resulfs should be mainfained. This enables projecf parficipanfs fo be better informed on issues facing fhe 
projecf and provides a record for fhe fufure. An official issue lisf should be mainfained, along wifh a lisf 
of quesfions for fhe vendor and vendor responses. Issue and question sfafus and closure should be 
recorded and periodically reviewed. 

I dentify And Resolve Legal I ssues Concerning Proprietary Documentation 

If a device contains proprietary software, legal arrangements must be made to permit inspection of 
propriefary documenfafion. Lack of access fo propriefary documenfs can resulf in undetected issues. 
One such example was fhe felemefry bandwidfh problem on fhe European Space Agency 
Cassini/Huygens Tifan probe. Telemefry requiremenfs for fhe Huygens dafa receiver on Cassini did nof 
include the effects of Doppler shift. This issue was nof discovered until a communications fest was 
performed while fhe probe was enroufe fo Safurn [42]. To compensafe for fhe error, fhe frajecfory was 
changed fo minimize fhe Doppler shift befween Cassini and Huygens. This slipped fhe Huygens arrival 
af Tifan from November 2004 fo January 2005. Factors fhaf confribufed fo fhe lafe discovery of fhe 
problem were lack of access to proprietary documentation, no end-to-end system testing and a lack of 
comprehensive projecf requiremenfs. 
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Inteiface Control Documentation (ICD) 

If the integrator and user do not have access to software and software requirements, the ICD may be the 
only written source of information on unit parameters. Developers of software that will interface with 
the unit must examine the ICD closely. The ICD and the interfacing software must be compared to each 
other throughout a project. The ICD should also be compared to ground and test results to ensure that it 
accurately reflects unit input, output and operation. An inaccurate ICD will lead to software and 
procedural issues that will have to be addressed before a system can be certified as operational. An 
accurate ICD is also needed for any data available in the lab (i.e. instrumentation port data) that might 
not be available once the unit is integrated into an operational system. This is critical in the test and 
verification phase of a project. 

Integrators should strive to understand operation of the software intensive devices as much as possible 
before defining requirements for code that will perform interface functions. Interfaces should be bullet 
proofed since it may not be possible to account for all forms of anomalous unit behavior. 

Short development schedules may result in changes to the ICD while host vehicle software requirements 
are being defined and software is in development and test. A disciplined process of checks must be in 
place to ensure that the ICD and software requirements for units that interface with each other are 
consistent. Individuals who are knowledgeable in requirements for various interfacing units must be 
able to communicate and be involved in any changes made to the ICD. 


Design I nsight 

Design insight is required for high-risk, safety-related applications for the COTS integration to be 
successful. Users of COTS units usually have little or no insight into software design, design rationale, 
and operation. Available documentation may not contain accurate, pertinent information that would aid 
an integrator in designing integration architecture, defining interface and software requirements, test and 
operational procedures, and issue identification and resolution. A vendor supplied Interface Control 
Document may not contain enough information to permit host system interface software requirements 
creation. Many devices, such as GPS receivers, contain legacy code, some of which may be one or more 
decades old. Vendor engineers may not have participated in the original development of the product. 
Over time, corporate knowledge loss concerning design rationale occurs due to retirements, employee 
attrition, office clean-ups, and corporate takeovers. This will make it difficult for the vendor to answer 
integrator and user questions. Vendor answers to questions may be limited to "how" a device operates, 
but not "why" it was designed to operate that way. If a vendor is not forthcoming concerning design 
insight, consultants and other users of the product may be able to provide information. 

As much design information as can be obtained is invaluable for determining if a device is really suitable 
for an application, and what hardware and software modifications are required for it to meet 
requirements. Lack of design insight makes this determination difficult. Issue identification, issue 
resolution and procedure development are also hindered by lack of design insight. Excessive amounts of 
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proprietary documentation and software also hinder the process, even if propriefary non-disclosure 
agreemenfs are in effecf. This can resulf in idenfificafion of serious fechnical issues lafe in fhe 
developmenf and fesf program, or affer operafional use has begun. Lack of design insighf can lead users 
fo affribufe suspecf performance fo fhe unif or some ofher componenf of an infegrafed sysfem, when fhe 
real problem is a lack of user undersfanding of fhe device and how if should be operafed. During a space 
mission, operafors of bofh unmanned and marmed spacecraff live by fheir dafa. Wrong informafion 
abouf sysfem funcfionalify can lead fo making fhe wrong decisions when faced wifh a spacecraff 
anomaly. This can lead fo loss of dafa, some vehicle capabilities [50] or even fhe spacecraff ifself, as in fhe 
1997 Lewis safellife incidenf [45]. Some form of knowledge capfure and managemenf should be 
implemenfed by developers, users and infegrafors fo ensure preservation of sysfem knowledge fhaf is 
critical for resolving issues and examining proposed reuse of soffware and hardware in new 
applications.’^ 

The ISS Experience With SI Gl Design I nsight 

The developers of fhe original Force 19 affifude deferminafion soffware were nof permiffed fo see fhe 
Force 19 code fhaf fhe affifude soffware would inferface wifh, as if was propriefary. Furfhermore, NASA 
JSC and confracfor personnel responsible for infegrafing fhe SIGI info fhe ISS avionics sysfem were nof 
permiffed fo see fhe affifude deferminafion code, as if was also classified as propriefary. These 
resfricfions complicafed SIGI flighf qualification, as well as resolution of SIGI issues once fhe unifs were 
operating on fhe ISS. This experience was one factor in fhe decision fo develop and mainfain a new sef of 
non-propriefary affifude deferminafion code owned by NASA (see Chapter 6, page 49). 

The Shuttle Experience With MAGR/ S Design I nsight 

For a flighf critical application (i.e., fhe box is required fo safely conclude fhe mission), a box will undergo 
more modification fhan in ofher applications. The user will also require more defailed knowledge of 
navigafion unif design and operation fhan users of non-safety critical units. The Shuttle Program 
considers a box to be failed more quickly fhan an aviation user. Engineering and Mission Confrol 
persormel musf have a fhorough undersfanding of receiver operation and dafa. For manned space flighf, 
lack of design insighf is a safefy issue. Due fo fhe anomalies fhaf occurred on STS-91, MAGR/S soffware 
requiremenfs, fhe infegrafion guide and source code (originally developed af govemmenf expense) were 
made available fo fhe Shuffle Program. A formal "questions for fhe vendor" lisf was mainfained and 
answers were recorded. 

The STS-91 incidenf revealed fhaf fhe Shuffle compufer soffware fhaf inferfaced wifh fhe MAGR/S was 
designed wifh an inadequate undersfanding of MAGR/S operation. The Shuffle soffware was later 
modified fo handle known and unknown receiver anomalies. Expanded vendor involvemenf affer STS- 
91 broughf much needed design insighf fo fhe projecf, which greafly aided issue idenfificafion and 
resolution. In hindsighf, some aspecfs of fhe MAGR/S inferface and infegrafion mighf have been done 
differenfly if fhe vendor had been involved when fhe Shuffle compufer soffware requiremenfs fo supporf 
GPS were initially defined. 

John L. Goodman, Knowledge Capture and Management for Space Flight Systems, NASA Contractor Report 
CR-2005-213692, October 2005. Available at http://ntrs.nasa.gov/ 
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Insight into test equipment design and operation is critical. Like vendors of GPS receivers, vendors of 
fesf equipmenf may nof undersfand fhe applications fhaf fheir equipmenf supporfs. Many issues fhaf 
arose during MAGR/S ground fesfing concerned GPS signal generafors. These issues had an impacf on 
fesf resulfs, cosf, and schedule. Insighf info GPS signal generator design and operation was a challenge 
fhroughouf fhe projecf. 

I mpact of Design I nsight on Science Missions 

Liffle or inaccurafe design insighf can complicafe or prevenf fhe use of GPS dafa in supporf of GPS 
technology demonsfrafions and scientific missions. Examples of fhis include GPS fechnology 
demonsfrafion payloads flown on fhe Shuffle. During fhe relative GPS experimenfs conducfed on STS-69 
and STS-80, lack of insighf info fhe 3M, TurboSfar, Tensor and Quadrex receivers made infegrafion, dafa 
processing and dafa analysis more difficulf. In addition, lack of insighf info algorifhms (parficularly 
fhose associafed wifh clock sfeering) made developmenf of fhe laptop based relative GPS navigation filter 
more challenging [12-15]. 


I ndependent Verification And Validation 

If if can be afforded, Independenf Verificafion And Validation (IV&V) is a valuable parf of a high risk or 
safefy critical projecf. Verificafion is fhe deferminafion of whefher or nof an ifem meefs fhe requiremenfs 
sef for if. Validation is fhe deferminafion of whefher or nof an ifem meefs ifs intended purpose in ifs 
operating environmenf. Validafion is parficularly imporfanf when an ifem or new fechnology is fo be 
used in an operafing environmenf fhaf if was nof originally designed for. The frend fo use non- 
developmenfal ifem avionics confaining propriefary soffware may prevenf IV&V of soffware in some 
safefy crifical applications. This is an issue for applications fhaf involve human safefy and unmanned 
applications requiring a high degree of aufonomy. 

IV&V of soffware requiremenfs and source code may reveal issues fhaf did nof arise during lab and 
flighf-fesfing. Guidelines should be creafed governing fhe scope of fhe audif. Issues should be examined 
fo determine if fhey represenf credible failure scenarios. 

The NASA IV&V confracfor played a significanf role in fhe MAGR/S projecf [62-66]. Initial IV&V 
involvemenf focused on fhe infegrafion archifecfure, ground fesf, and flighf fesf resulfs. After MAGR/S 
cerfificafion was posfponed in fhe wake of fhe STS-91 incidenf (1998) and MAGR/S soffware (originally 
developed for fhe Deparfmenf of Defense af governmenf expense) was made available fo fhe Shuffle 
Program, IV&V performed an audif of fhe soffware sfarfing in 1999. IV&V personnel possessed prior 
experience wifh fhe MAGR on aircraff infegrafions. The IV&V confracfor played a valuable role in 
idenfifying, assessing fhe crificalify of, and assisfing wifh fhe resolution of soffware issues. The audif was 
invaluable in fhe cerfificafion process, buf should have been conducfed much earlier in fhe projecf. 
Several hundred issues, of varying degrees of severify, were idenfified and disposifioned fhrough fhe 
IV&V analysis of fhe MAGR/S requiremenfs and soffware. 
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Orbit Determination Accuracy 


While accuracy of COTS navigation units may be sufficient in some cases to support low accuracy space 
flight requirements. Shuttle flights of these units indicate that they are not appropriate for future 
applications with more demanding orbit determination needs. 

Formation flying, elimination of ground tracking and orbital replenishment (rendezvous, proximity 
operations and docking) will place stringent demands on orbit determination and relative navigation 
accuracy [67]. Software quality, hardware reliability and orbit determination accuracy requirements to 
support these applications will be more demanding than the capabilities of current GPS units. 
Autonomous, on-board, real time navigation, relative navigation and bum targeting requires investment 
in spacecraft navigation systems that will differ from atmospheric flight navigation systems. 

Velocity Accuracy I s I mportant 

Targeting algorithms that compute precise orbital adjustments to support activities such as (but not 
limited to) formation flying, rendezvous, proximity operations and docking/grapple need accurate 
velocity as well as position. Such algorithms have to predict vehicle state vectors into the future over a 
period of time that may range from minutes to weeks. Even small velocity errors can result in large 
position and velocity errors after a prediction using high fidelity integrators and environment models. 
How well a navigation unit state vector predicts into the future is a key question that potential users of a 
unit must ask and address during flight and lab test evaluation. 

Orbital Semi-Major Axis 

A metric used to evaluate how well a state vector will predict is the semi-major axis [68] accuracy. 
Orbital semi-major axis is a function of position, velocity and energy (1). It is also related to the period of 
the orbit (2). 
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Relative semi-major axis accuracy is a good parameter for judging the accuracy of a relative GPS 
algorithm for formation flying and rendezvous applications. 


A recent journal article addresses the importance of semi-major axis accuracy and the need for realistic 
correlation between position and velocity [23]. This article was written in response to the poor 
navigation performance observed on Shuttle flights of off-the-shelf GPS receivers and EGIs. 
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Most Space Navigation Conference Papers Do Not Address High Accuracy Orbit 
Determination 

Some papers appearing in the literature advocate geometrical, kinematic type position-determination 
techniques using GPS data. The advent of all-in-view receivers supports this trend. Such algorithms take 
advantage of confinuous, high rafe GPS measuremenfs and fhe improved measuremenf geomefry 
compared fo ground based radar fracking. From a soffware perspecfive, fhese algorifhms are more 
sfraighfforward since complex environmenf models (such as gravity and drag) are not used. While the 
position and time data resulting from kinemafic posifioning algorifhms are very accurafe and meef fhe 
requiremenfs of some missions, fhis solves only half fhe problem for ofher users. 

Many papers discuss a range of space applicafions of GPS and fhe high-posifion accuracy if offers, buf 
pay liffle or no affenfion fo fhe need for accurafe velocify and semi-major axis esfimafion. Numerical 
resulfs of algorifhms designed fo improve spacecraff navigafion accuracy are exclusively focused on 
posifion accuracy, wifh no menfion of velocify and semi-major axis errors. Ghallenges in spacebome 
applicafions of GPS are offen defailed, such as: 

• Widening fhe Doppler shiff window. 

• Insfalling an orbif propagafor fo facilifafe reacquisifion affer a GPS oufage. 

• Mulfipafh 

• GPS safellife visibility as a function of spacecraff affifude. 

• GPS safellife visibility to antennas on spinning spacecraft. 

• Increased number of safellifes visible on-orbif. 

• Safellife visibilify and signal sfrengfh for geosfafionary safellife applicafions. 

• Modifying legacy navigafion algorifhms fo accommodafe higher orbifal alfifudes and velocifies. 

However, fhe need fo improve navigafion and filfering algorifhms fo enhance velocify and semi-major 
axis accuracy is rarely menfioned. Lack of orbifal and relafive semi-major axis accuracy dafa, along wifh 
posifion and velocify correlafion dafa, make if difficulf fo evaluafe fhe usefulness of relafive GPS 
navigafion sfudies and algorifhms published in fhe liferafure. Such dafa is required fo assess navigafion 
accuracy impacfs on fargefing and guidance algorifhms and perform propellanf budgefing. 

Receiver Specifications 

Receivers have specificafions for expecfed posifion and velocify accuracy under fhe besf fracking 
condifions. Even receivers designed for space lack a semi-major axis specificafion. This, coupled wifh 
fhe propriefary nafure of receiver soffware, makes if difficulf for pofenfial users fo defermine how 
suifable a receiver may be for a space applicafion. 

Navigafion unifs fhaf are needed fo supporf advanced concepfs (formafion flying, rendezvous, 
aufonomous operafion, limifed ground supporf and infrasfrucfure) require navigafion algorifhms fhaf 
reflecf orbifal mechanics. While if is frue fhaf posifion, velocify and orbifal paramefer accuracy 
requiremenfs vary from program fo program, fhis should nof be used fo jusfify a lack of appropriafe 
navigafion algorifhm missionizafion. 
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COTS Box Outputs May Not Be Designed With Redundancy Management I n 
Mind 


Most aircraft and missiles use only one GPS receiver, stand-alone Inertial Navigation System (INS) or 
Embedded GPS/INS (EGI). Some vehicles (Space Shuttle, ISS, X-33, X-38) were designed to use multiple 
navigation units for redundancy. Redundancy Managemenf (RM) schemes perform checks on box 
oufpufs, such as dynamic paramefers (posifion, velocity, attitude, rotational rate and accumulated sensed 
velocity) and health status parameters (Built-In Test/Built-In Test Equipment, BIT/BITE). Most BIT/BITE 
indicators and self-tests were designed to help ground personnel determine if a suspecf unif should be 
refumed fo fhe depof for mainfenance. 

Use of BIT/BITE indicators in RM algorifhms requires fhaf fhe infegrafor undersfand whaf fhe healfh 
sfafus indicafors mean and how indicafions of a problem can affecf navigafion unif performance. Gare 
musf be faken when defermining which paramefers fo monitor for assessing unif healfh. A fifle of whaf 
fhe indicafor is in an inferface confrol documenf does nof fell fhe infegrafor fhe pofenfial impacf fhe 
annunciafed condifion has on box performance. This makes if difficulf for fhe infegrafor fo defermine 
which BIT/BITE indicafions should be used in fhe RM algorifhm. The RM scheme should be robusf 
enough fo identify and deselecf a quesfionable unif buf nof deselecf a good unif. BIT/BITE indicafors in 
navigafion unifs evolve over long periods and have a herifage going back decades fo previous producfs. 
Particular indicafors are offen added fo help address cerfain problems encounfered. Over fhe years, 
corporafe knowledge loss resulfs in a manufacfurer no longer knowing why a particular indicafor is 
presenf in fhe oufpuf or whaf ifs significance is. Of parficular imporfance are whaf values performance 
indicafors (such as Figure of Merif) are inifialized fo after a unif power cycle or re-inifializafion. 

Unlike aircraff, fhe Space Shuffle performs BIT on navigafion unifs during flighf. Mission Gonfrol musf 
undersfand how fo inferpref negative resulfs. Does a cerfain failure indication from BIT always mean 
fhaf fhe unif should nof be used? Gould fhe unif continue fo be used for navigafion wifh no degradation 
in performance? Nuisance indicafors need fo be idenfified and ignored. A BITE masking capability is 
particularly useful. 

While redundancy managemenf is imporfanf, if is nof a subsfifufe for well-documented and fully verified 
soffware. 


Do Not Totally Rely On The Vendor For Navigation Expertise 

Vendors can provide valuable information on fhe design, infegrafion, and use of fheir producfs. 
However, fhey may nof always fully undersfand fhe applicafions where fheir producfs are used. Users 
and integrators musf mainfain navigafion experfise fo conducf fesfing, resolve issues, avoid "false pulls" 
of healfhy unifs fhaf are assumed fo be malfunctioning [69], defermine how besf fo infegrafe a unif, and 
provide managemenf wifh advice on whaf navigafion producfs are suifable for an upgrade. Navigafion 
vendors, who are doing business in a highly competitive markef, do nof wanf skilled fechnical personnel 
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tied to one project for periods of years. The use of a COTS navigation producf should nof lead one fo 
believe fhaf fechnical expertise can be "boughf" as a COTS producf. 


Vulnerability to Space Radiation 

Each succeeding generafion of elecfronic devices, such as GPS receivers, use smaller and smaller 
elecfronic componenfs. This may make modern GPS receivers more susceptible fo space radiafion upsefs 
fhan fhe legacy receivers. The higher suscepfibilify of new receivers fo radiafion makes use of GPS prior 
fo and during safefy-crifical flighf phases (such as deorbif) questionable. A modern receiver may require 
expensive modification fo meef reliabilify requiremenfs, or fhe required reliabilify may have fo be 
lowered. 


The Challenge Of Autonomous, On-Board Navigation 

Aufonomous operation of spacecraff sysfems has long been a desire fo reduce operafions cosfs. 
However, such a requiremenf poses high reliabilify requiremenfs on sysfem componenfs. Soffware safety 
is an important consideration in any aerospace system [9, 40, 57]. 

Rather than being viewed as off-the-shelf, plug-and-play unifs, GPS receivers are complex compufers fhaf 
inferacf wifh ofher complex compufers. The GPS and hosf vehicle compufer incidenfs on Discovery 
(June 1998) and ISS (Sepfember 2002) illusfrafe fhaf GPS receivers and hosf vehicle compufer sysfems can 
inferacf in a dysfunctional manner wifh resulfs fhaf are vehicle wide and nof anficipafed. Even a GPS 
receiver in non-safefy-crifical funcfions could fhreafen safety of flighf by affecting safety critical systems 
such as flight computers and communications systems. Non-safety-critical receivers may require an 
extensive testing and certification process for an aufonomous application, or fhe hosf vehicle avionics 
sysfem musf be robusf enough fo survive known and posfulafed dysfunctional inferacfion befween 
sysfem componenfs, and recover fo a safe sfafe. 

Roadblocks fo achieving on-board navigation aufonomy include on-board sysfem capacity, cost, schedule 
and technical complexity. Trade-studies may have to be conducted to determine the level of aufonomy 
fhaf is commensurafe wifh mafurify of fhe fechnology, on-board sysfem capacity, and available schedule 
and budget. If fhe available GPS receivers do nof meef orbif deferminafion requiremenfs as builf, fhe 
chosen receiver will eifher have fo be modified, or additional orbif deferminafion soffware placed on fhe 
spacecraff. The orbif deferminafion function may even have fo be performed on fhe ground. 

One example of a frade-off befween on-board complexify and aufonomy is fhe Swedish Space 
Corporation Odin aeronomy safellife, which is equipped wifh fwo GPS receivers. To reduce on-board 
complexify, if was decided fo perform precision orbif deferminafion on fhe ground using down linked 
GPS dafa, rafher fhan on fhe safellife. The receivers require periodic re-inifializafions, and commands are 
senf from fhe ground fo accomplish fhis [70]. 
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It is important to carefully assess the maturity of a fechnology, even if fhere is pofenfial fhaf fhe 
fechnology could enable aufonomy and reduce development infegrafion, and life cycle cosfs. A proven, 
buf initially more expensive solution, may save money in fhe long run. 


Navigation Conferences 

Receiver reliabilify and robusfness is seldom addressed af navigation conferences. Reporfs on new GNSS 
applications and infegrafions rarely highlighf fhe more mundane process problems fhaf were 
encounfered when implementing and using GNSS fechnology. Problems wifh hardware and soffware 
procurement soffware qualify, lack of information on receiver design and operation, poor 
communicafion befween projecf parficipanfs, poor vendor support cosf and schedule problems, fesf 
equipmenf issues, and inaccurafe documenfafion are rarely mentioned in papers or keynofe speeches, buf 
are offen discussed informally by fechnical personnel oufside conference forums. Vendor feedback fo fhe 
user communify is offen missing. The fendency fo avoid mentioning problems makes if difficult if nof 
impossible, for GNSS infegrafors and users fo learn how ofher users and infegrafors overcame process 
challenges fo bring a projecf fo a successful conclusion. 

Gonference agendas should include lessons learned sessions fhaf facilifafe discussion among users and 
infegrafors. Besf pracfices carmof be identified and communicafed if problems and fheir solutions are nof 
discussed. There should be a willingness fo discuss negative aspecfs of projecfs, including projecf 
failures, while sticking fo fhe facfs and nof assigning blame fo individuals or organizations. A vendor 
feedback session, feafuring a panel of vendor represenfafives, may allow users and infegrafors fo become 
aware of common problems observed by vendors from having worked wifh a large cusfomer base. 
Vendor commenfs should nof be limifed fo perceived obsfacles fo selling fheir producfs. Tuforials on 
process engineering (i.e., soffware development fesfing, certification, device selecfion, infegrafion, projecf 
managemenf) as applied fo fhe navigation indusfry may be helpful fo conference parficipanfs. 
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6.1 nternational Space Station 


In 1993, GPS was chosen over star trackers for ISS attitude determination. Although star trackers had a 
high state of technology readiness, it was believed that use of GPS for affifude determinafion would 
lower developmenf and infegrafion cosfs. GPS posifion, velocify, and fime would be used by fhe ISS as 
well. 


ISS Space I ntegrated GPS/1 NS 

The Space Infegrafed GPS/Inerfial Navigafion Sysfem (SIGI) was a projecf to develop a common 
spacecraft navigator for bofh manned and unmanned vehicles [2, 3, 71]. The Force 19 GPS receiver in fhe 
SIGI was specifically developed for fhe ISS applicahon. The Force 19 affifude deferminafion soffware 
was developed by NASA and furnished fo fhe GPS vendor as Governmenf Furnished Equipmenf (GFE). 
The ISS SIGI came equipped wifh a sfrapdown Inerfial Measuremenf Unif, alfhough af fhe fime fhere was 
no ISS requiremenf for fhe sfrapdown acceleromefer and ring laser gyro data. Blended filter data from 
fhe SIGI is nof used. Two SIGI unifs are locafed in fhe U.S. laboratory module Destiny. Four GPS 
anfennas, each equipped wifh choke rings for mulfi-pafh mifigafion, are af fhe corners of a 1.5 by 3 meter 
reef angle on fhe SO fruss (Figures 1 and 2) [2]. 



Figure 1 - One of the four ISS GPS antenna and choke 
ring assemblies prior to launch. The assembly is 10.81 
inches wide. 


A Kalman filter was implemented in the SIGI for position and velocity determination in the presence of 
Selective Availability (SA). However, the deactivation of SA and technical issues with the filter has 
driven the ISS Program to rely on the deterministic position and velocity solution from the Force 19. 


One hundred foot long cables connect the antenna assemblies to the SIGI units. Double differencing was 
used to cancel out cable biases than could not be determined before the hardware was brought to the ISS. 
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Figure 2 - Close up of ISS GPS antenna array location. This photograph was taken on STS-111 
following undocking over western Kazakhstan on June 15, 2002. Endeavour \n as conducting a fly- 
around of the ISS. The docking port is pointed along the velocity vector. 


Most of the attitudes flown by the ISS do not allow the GPS antenna boresights to be pointed along the 
zenith direction [72, 73]. ISS SIGIs are provided with antenna pointing information to facilitate satellite 
acquisition. 
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Ground Testing and Shuttle Test Flights of ISS SI Gl 


Lab Tests 

An array of flight qualification tests were conducted in ground facilities, using both GPS signal 
generators and live sky antenna arrays. Complex mathematical models were developed and lab testing 
performed in an attempt to subject the SIGI to the multi-path rich ISS radio-frequency environment [2, 
74]. However, lab testing could not exactly duplicate the ISS radio-frequency environment. 

Flight Tests 

Attitude determination algorithms used in the ISS SIGI were first tested in a TANS Vector GPS receiver 
flown on STS-77 {Endeavour, May 1996, Table 3) as a part of the GPS Attitude and Navigation Experiment 
(GANE) [75, 76]. The GANE hardware was mounted in the payload bay. ISS SIGIs were flown for data 
collection in the SIGI Orbital Attitude Readiness (SOAR) experiment on two Shuttle missions, STS-101 
{Atlantis, May 2000) and STS-106 {Atlantis, September 2000) to test position, velocity and attitude 
determination [77]. SOAR used much of the GANE hardware, and was also in the payload bay. Star 
trackers collocated with the SOAR hardware provided a check on Force 19 attitude determination. While 
these flights did provide valuable on-orbit data, they could not subject the SIGI to the exact multi-path 
and signal obscuration environment later encountered on ISS. 


SI Gl Flight Experience on the I SS 


The two SIGI units arrived at the ISS when the Destiny module was delivered on assembly flight 5A (STS- 
98, Atlantis, February 2001). GPS become operational on ISS after the SO truss was installed on assembly 
flight 8A (STS-110, Atlantis, April 2002). Actual use on the ISS was the first time the ISS SIGI was used 
during extended (longer than a Shuttle mission) flight. 


Table 3 - Shuttle and Progress Missions Related to ISS SIGI 


Mission 

Year 

Spacecraft 

ISS GPS Objective 

Primary Mission Objectives 

77 

1996 

Endeavour 

GANE GPS attitude test 

SPARTAN deploy/retrieve, SPACEHAB 

101 (2A.2a) 

2000 

Atlantis 

SOAR SIGI testing 

ISS resupply and outfitting 

106 (2A.2b) 

2000 

Atlantis 

SOAR SIGI testing 

ISS resupply and outfitting 

98 (5A) 

2001 

Atlantis 

SIGI delivery to ISS 

Deliver Destiny \dlo module 

110 (8A) 

2002 

Atlantis 

GPS antenna array delivery 

Deliver SO truss & Mobile Transporter 

14P 

2004 

Progress M-49 

Deliver new SIGI software 

ISS replenishment. Docked 5/27/04 

15P 

2004 

Progress M-50 

Deliver SIGI loader cable 

ISS replenishment. Docked 8/14/04 
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Use of GPS by ISS 


Force 19 deterministic position and velocity data must pass quality assurance checks and a selection filter 
before fhey are incorporafed info fhe ISS compufer navigation solution. The Force 19 deferminisfic sfafe 
vecfor musf meef an orbif deferminafion accuracy requiremenf of no greafer fhan 1,000-foof fhree-sigma 
semi-major axis error fo supporf Ku Band anfenna pointing fo TDRSS safellifes. GPS affifude dafa is 
filfered in an ISS compufer along wifh rafe gyro dafa (nof from fhe SIGI) fo defermine an affifude solution 
fhaf meefs fhe ISS 0.5-degree 3 sigma per axis affifude accuracy requiremenf. While fhe SIGI and fhe ISS 
affifude confrol sysfem have mef requiremenfs for affifude, posifion, velocity, and time determination 
accuracy, numerous technical issues surfaced fhaf impacfed solution availability. Most of fhe issues were 
discovered affer ISS SIGI operations began in April of 2002. Idenfificafion and recovery from many of 
fhese problems required Mission Gonfrol and asfronauf/cosmonauf infervenfion, which added addifional 
work fo already complex ground and crew timelines. 

I mpact of One Force 19 I ssue 

On Sepfember 22, 2002, and again on fhe following day, a Force 19 soffware error nof recognized in 
ground fesfing occurred fhaf caused fhe SIGI fo emif a fype of oufpuf fo fhe ISS Guidance, Navigation 
and Gonfrol (GNG) soffware fhaf was nof anficipafed by sysfem infegrafors. The oufpuf caused ISS GNG 
compufers fo go info a diagnosfic mode, which resulfed in fhe mission impacfs lisfed in Table 4. If was 
known and documenfed fhaf fhe ISS compufer could nof handle fhe oufpuf in quesfion, buf during fhe 
infegrafion and fesf phase, no evidence was nofed fhaf any avionics would supply fhaf fype of oufpuf fo 
fhe ISS compufers. The SIGI unifs were fumed off for several weeks, until a soffware pafch was 
developed and applied fo fhe ISS GNG soffware. The pafch enabled ISS compufers fo handle fhe 
spurious oufpuf wifhouf infermpfing normal operation. Subsequenf emissions of fhe spurious oufpuf by 
fhe SIGIs were correcfly handled by fhe ISS compufers wifh no ill effecfs. 


Table 4 - Operational I mpacts of SI Gl I nduced I SS Computer Crash 

• Transfer of attitude control from the U.S. Segment control moment gyros to the Russian segment 
thruster system 

• Contingency attitude control using valuable and carefully managed propellant supplies 

• Labor intensive manual S band antenna pointing by MCC Houston to maintain data and voice 
communications 

• Loss of Ku band data transmission capability 

• Loss of micro-gravity environment due to attitude control thruster firings 

• Loss of a crew day of science operations 


52 of 118 




Solution Availability 


Another issue was limited solution availability. Due to non-optimal antenna pointing, signal obscuration, 
and the rich multi-path environment, the GPS attitude determination function frequently has to solve for 
integer ambiguities in carrier phase. Up to an hour may be spent solving for the ambiguities, and the 
receiver will not output a position and velocity during these periods, the time and duration of which are 
not predictable. This feature of the unit was known before use on-board the ISS began, and was judged 
not to be an impact to the ISS antenna-pointing requirement. However, it was an impact to ground 
processing of Force 19 data, which will be discussed in the next section. No requirement was levied on 
the unit for the maximum acceptable position, velocity or attitude outage. 


ISS Spacecraft Position Optimal Tracking (SPOT) Filter 

Why Filter GPS States? 

There were no requirements for the Force 19 to perform precision ISS orbit determination. Ground radar 
tracking of the ISS is only performed by Mission Gontrol Houston to support Shuttle rendezvous. 
Although coherent S-Band TDRSS transponders are carried by the ISS, there are currently no plans to 
process TDRSS Doppler from ISS in Mission Gontrol, as is done for the Shuttle. Historically, continuous 
tracking of the ISS by U. S. Strategic Gommand was the source of ISS orbit data used for ISS debris 
avoidance efforts and mission planning conducted by Mission Gontrol Houston. A Mission Gontrol 
based GPS ground filter (ISS SPOT), similar to the one developed for the Shuttle MAGR/S data, was 
developed to process Force 19 deterministic state vectors to provide high accuracy orbit determination to 
support collision avoidance, orbit maintenance, rendezvous plarming, and to augment ground radar 
tracking in support of Shuttle rendezvous. 

Processing SI Gl Flight Test Data 

Force 19 deterministic state vector data from flights of the ISS and X-38 SIGIs on Shuttle missions STS-101 
SOAR (Table 3, page 51) and STS-108 (Table 1, page 21) were processed by the ISS SPOT filter during 
development. The flight data was useful in developing and tuning the filtering algorithms. However, 
these test flights did not provide insight into Force 19 performance in the radio-frequency environment of 
the ISS, nor was Force 19 data processed by ISS telemetry software. 

I SS SI Gl Data and SPOT 

Once the SIGI units were in operation aboard the ISS, Force 19 data was processed by the developmental 
version of the ISS SPOT filter. While the filter successfully performed orbit determination to a higher 
level of accuracy than the Force 19, data problems severely limited the time spans over which orbit 
determination could be performed. Frequent loss of integer ambiguity solutions prevented Force 19 
output of position and velocity estimates. Furthermore, much of the required data was not time 
homogeneous. Even if the Force 19 was computing position and velocity data, variations in ISS telemetry 
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format content and low SIGI data priorities prevented acquisition of the input required for the ISS SPOT 
filter. The frequent lack of Force 19 position and velocity vectors caused the SPOT filter to converge 
much more slowly, or even prevented orbit determination from occurring in the first place. Lack of a 
suitable and unambiguously defined Force 19 solution quality indicator complicated processing of Force 
19 data by SPOT. 

Most of the ISS SPOT development effort focused on a pre-processor to weed out unacceptable Force 19 
data before it reached the orbit determination filter. Development of the pre-processor required extensive 
analysis of SIGI data and complicated the software development process, resulting in schedule problems. 
ISS SPOT has been certified for flight use, and will provide improved orbit estimates for mission plarming 
after a flight-following period in Mission Gontrol. 


SI Gl Software and ISS Telemetry Changes 

Since April of 2002, SIGI performance has been continually assessed, and modifications to Force 19 
receiver and SIGI input/output software were identified, developed, tested, and flight qualified. In 
addition, a new set of attitude determination code was developed, tested, and flight qualified, which 
resolved many performance issues. Due to the grounding of the Shuttles following the Columbia accident, 
the new SIGI software and a laptop-to-SIGI software loader cable were sent to the ISS on two Progress 
flights (Table 3, page 51) launched from the Baikonur Gosmodrome. 

New Attitude Determination Software 

The NASA SIGI team at the Johnson Space Genter developed the new code, which is government owned 
and maintained, whereas the original Force 19 attitude determination software was developed by a 
different NASA organization and became proprietary after delivery to the receiver vendor. The new 
attitude determination software used a different method of integer ambiguity resolution and attitude 
determination, which significantly increased attitude solution availability. 

In response to the software issues encountered with the original attitude determination code, the software 
development and testing process for the new code was significantly different. All attitude determination 
code and associated software development and testing tools were placed under strict configuration 
management. Goding standards were followed, code audits were performed, and modules were 
exhaustively tested on a workstation using both nominal and off-nominal input data. All lines of code 
and software paths were tested. Built-in error words were placed in the code, which greatly aided 
software anomaly analysis once the new attitude determination software was placed in the Force 19. In 
addition, all developmental software versions were meticulously documented and saved for future 
reference. The software and test cases were completely documented, and the theoretical development of 
and assumptions inherent in the new attitude determination algorithm were thoroughly documented. 
Since the new software is not vendor proprietary, NASA JSG SIGI and associated ISS contractor 
personnel have complete access to requirements, source code and theoretical development 
documentation. This greatly aids verification and anomaly investigation efforts. 
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Initialization data was placed in the new attitude determination software to lower the amount of work 
required by Mission Confrol personnel fo recover fhe SIGI affer a power cycle. The capabilify fo adjusf 
addifional affifude deferminafion algorifhm paramefers from Mission Confrol was also added. Solufion 
of carrier phase infeger ambiguities was decoupled from posifion and velocify deferminafion, which 
resolved fhe exfended posifion and velocify oufage issue. 

New SI Gl and Force 19 Software 

Bofh fhe SIGI and Force 19 vendors resolved software and performance issues nof associafed wifh the 
attitude determination function. To improve ISS re-boost maneuver monitoring and post-bum orbit 
determination by Mission Control Centers in Moscow and Houston, the SIGI and ISS GNC software has 
been modified so fhaf infegrafed acceleration from fhe SIGI sfrapdown IMUs can be incorporafed info fhe 
ISS GNC processing and downlisfed fo fhe ground. 

ISS Telemetry Changes 

ISS SPOT developers identified several problems in Force 19 dafa thaf were due fo ISS felemefry formal 
and confenf. Several changes were made fo felemefry requiremenfs fo ensure fhaf fhe ISS SPOT inpuf 
dafa would be grouped fogefher in fhe same dafa packefs, were fime homogenous, and would be presenf 
in fhe felemefry sfream when needed. 


Other GPS Receivers On The I SS 

For complefeness, if should be poinfed ouf fhaf fhere are ofher GPS receivers on fhe ISS, which were nof 
fesf flown on fhe Space Shuffle. Two ASN-2401 navigation sysfems, confaining ASN-22 GPS/GLONASS 
GPS cards, are in fhe Russian builf Zvezda Service Module [78]. They supply navigation dafa for fhe 
Russian segmenf of ISS. Two Laben Tensor unifs will also be carried on fhe European builf Aufomafed 
Transfer Vehicle (ATV) fo supporf aufomafed rendezvous, in conjuncfion wifh fhe ASN-2401 unifs on fhe 
Service Module. The ASN-2401 unifs will be upgraded fo supporf relative navigation before fhe ATV 
flighf operations begin. Two SIGIs will be on fhe Japanese Experimenf Module (JEM) and fhree on fhe 
Japanese Transfer Vehicle (HTV) fo supporf rendezvous. The SIGIs contain Trimble Force 5 GPS cards. 
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7. The Space Shuttle and GPS 


In the 1970s, the Space Shuttle was designed with three TACAN units for use during the entry phase of 
flighf. By fhe lafe 1970s, wifh the NAVSTAR GPS program promising a revolution in navigation, the use 
of GPS on fhe Shuffle orbifers was sfudied [79]. The orbifers Discovery, Atlantis and Endeavour were all 
manufactured in the 1980s with GPS antennae and associated wiring. However, due to budget concerns 
and the developmental nature of GPS, a GPS upgrade fo fhe Shuffle sysfem was nof pursued. 


In 1990, fhe infroducfion of GPS had led fhe 
Deparfmenf of Defense and fhe Federal Aviation 
Administration to plan the phase out of TAG AN 
ground sfafions begirming in fhe year 2000 (Table 5). 
GPS promised better performance fhan TAG AN and 
reduced operafing cosfs. In response, then Shuttle 
Program Manager (and former asfronauf) Roberf 
Grippen inifiafed an efforf fo study the possibility of 
replacing fhe fhree TAGAN unifs on each orbifer 
with three GPS receivers (Figure 3). 


Table 5 - Planned TACAN Phase-Out 
From The Federal Radionavigation Plan 


Planned Start of 

FRP Publication Date TACAN Phase-Out 


1990 

1990 

2000 

1992 

J une 1993 

2000 

1994 

May 1995 

2000 

1996 

July 1997 

2005 

1999 

December 1999 

2008 

2001 

March 2002 

2010 

2005" 

? 

? 


3 The 2005 Federal Radionavigation Plan was 
not available at the time of publication. A 
2003 Plan was not published. 



Figure 3 - Eventual phase-out of TACAN ground stations led NASA to 
upgrade a proven and highly successful Shuttle navigation system. 


57 of 118 






















By 1996, the development of Embedded GPS/INS (or EGI) units employing strapdown inertial sensors 
[80] motivated the Shuttle program to look at an eventual replacement of fhe previously menfioned sfand 
alone GPS (fhe TACAN replacemenf) and sfable member, spirming mass gyro Kearfoff High Accuracy 
Inerfial Navigafion Sysfems (HAINS) Inerfial Measuremenf Unifs (IMUs) wifh EGIs. The use of 
sfrapdown IMUs employing ring laser gyro (REG) fechnology was idenfified as a pofenfial source of cosf 
and schedule savings during orbifer pre-launch processing. 

Bofh fhe TACAN replacemenf and GPS/IMU replacemenf efforfs were conducfed in parallel. Sfudies 
were performed fo defermine fhe besf infegrafion archifecfure. Sfand-alone GPS unifs and EGIs had fo be 
infegrafed in a manner fhaf did nof compromise fhe infegrify of an operafional, cerfified navigafion 
sysfem. Once if was decided fo failor fhe GPS receiver requiremenfs fo TACAN replacemenf, sfudies 
were conducfed fo defermine if fhere were ofher applicafions for GPS during Shuffle flighfs. 

Changes fo fhe Shuffle General Purpose Compufers (GPCs) fo supporf bofh projecfs were idenfified. GPS 
and EGI hardware was selecfed; inferface, soffware and hardware changes were idenfified and made. 
Bofh fypes of unifs were flown on a series of Shuffle missions for fesf and evaluafion. Modificafions were 
made fo GPS and EGI soffware based on flighf fesf resulfs. 


Overview Of Space Shuttle Navigation System 

Navigafion requiremenfs for manned spacecraff are differenf fhan fhose for ferresfrial aircraff, unmanned 
Earfh orbifing safellifes and inferplanefary probes [81, 82]. The guidance, navigafion and flighf confrol 
sysfem had fo be designed fo ensure safefy of flighf and mission success for ascenf, orbif, rendezvous and 
gliding enfry fo a runway landing in fhe presence of sysfem failures. For ascenf and enfry, a fofal of five 
compufers, running in parallel, can confrol fhe vehicle. Four of fhe GPCs run whaf is known as fhe 
Primary Flighf Soffware Sub-sysfem (PASS) soffware. The fiffh runs Backup Flighf Soffware (BPS). 
Differenf confracfors coded PASS and BPS soffware. The BPS confains a subsef of fhe PASS funcfionalify 
fo enable fhe vehicle fo finish nominal ascenf, an aborf or landing in fhe evenf of a generic PASS soffware 
failure. While on orbif, only PASS soffware provides guidance, navigafion and flighf confrol funcfions. 
Mulfiple navigafion sensors, command pafhs and power buses wifhin fhe avionics sysfem ensure 
redundancy [83, 84]. Navigafion sensors used in fhe "pre GPS era" are depicfed in Table 6. 

For HAINS IMUs, TACANs, baromefric alfimefers and MLS unifs, redundanf measuremenfs are passed 
fhrough Faulf Defecfion, Idenfificafion and Reconfigurafion (FDIR) algorifhms [85]. Selecfion filfers fhen 
process dafa from unifs deemed fo be good. Selecfed measuremenfs are fhen passed fo fhe Shuffle 
navigafion soffware. HAINS IMU dafa is used during all flighf phases for affifude and sensed velocity 
determination. During entry, PASS and BFS Kalman filters process selected TACAN, IMU derived 
altitude and barometric altimeter measurements. Only the PASS Kalman filter processes selected MLS 
data. Selected radar altimeter data is provided for crew sifuafional awareness, buf is nof incorporafed 
info fhe navigafion solufion. 
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Table 6 - Legacy Space Shuttle navigation sensors. GPS supplements TACAN in the "single string" 
(one GPS) configuration. "Three string" GPS (three receivers) will replace the three TACAN units. 


Ascent 

Orbit and Rendezvous 

Entry 

• Three High Accuracy 
Inertial Navigation 

• Three HAINS IMUs 

• Two Hand Held 

Lasers (HHL) 

• Three HAINS IMUs 

System Inertial 
Measurement Units 

• Two Star Trackers 

• Two payload bay 

• Three TACANs 

(HAINS IMUs) 

• One Ku band 

television cameras 

• Four Barometric 

• Ground based C & S 

rendezvous radar 

with ranging ruler 
overlays 

Altimeters 

Band radar tracking 

• One Crew Optical 


• Three Ku Band 


Alignment Sight 

• Ground based C band 

Microwave Landing 


(COAS) 

radar tracking 

System (MLS) 

Receivers (on-board) 


• One Trajectory 
Control Sensor 

• Tracking And Data 

Relay Satellite 

plus ground equipment 


(TCS, a laser) 

System (TDRSS) 

• S Band Doppler 
tracking 

• Two Radar Altimeters 

• Ground based C & S 
Band radar tracking. 

• At least two TACAN 
ground stations. 


During rendezvous, a PASS Kalman filter processes on-board radar, star tracker and Crew Optical 
Alignment Sight (COAS) measurements. TCS and HHL data are processed in Kalman filters residing in a 
laptop computer for crew situational awareness. Television monitors with ranging ruler overlays 
provide range information to the crew during docking. The angle subtended by the target in the COAS is 
also a back-up source of range data. 


I ntegrating GPS I n A Loosely Coupled Architecture 

A loosely coupled architecture using cascaded filters is a common way of upgrading existing navigation 
systems with GPS. This method of integration has been used on platforms such as the F-16 [86], F-117 

[87] , Conventional Air Launched Cruise Missile [88] and B-2 [89]. 

A cascaded filter approach involves using the position output of the GPS receiver as a measurement for a 
Kalman filter in the host vehicle navigation system [86]. Position and velocity aiding data from the host 
vehicle INS are fed back to the GPS receiver to improve signal acquisition and tracking performance. 
Fiowever, the Kalman filter is derived under the assumption that measurements are not time correlated. 
This assumption is violated by processing the GPS position vector in the host vehicle Kalman filter. Time 
correlated measurements can lead to filter instability. This problem has been avoided in many 
applications by processing GPS position vectors at a low rate, such as no higher than every 15 seconds 

[ 88 ] . 
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One option considered was to process GPS position vectors as measurements in the PASS and BPS 
Kalman filters, as is done in many military applications. 

Another option studied was to convert GPS position into a TAGAN measurement (known as "TAGAN 
transparency"). This was an attempt to minimize or avoid changes to the PASS and BPS flight software 
and input/output. This would have resulted in a high rate cascaded filter implementation (TAGAN 
measurements are processed every 3.84 seconds). A "transparent" approach would not have allowed 
INS aiding to be supplied to the receiver from fhe GPG. Grew displays required GPS receiver specific 
confrols and qualify assessmenfs, and GPS dafa needed fo be senf fo Mission Gonfrol for fhe flighf 
confrollers. Por on-orbif processing, a new Kalman filler would have fo be creafed. On-orbit processing 
of "pseudo TAGAN" measuremenfs could only have been performed wifhin fhe line-of-sight of fhe 
TAGAN sfafions already in fhe flighf soffware fo supporf landing. 

Neifher of fhe loosely coupled, cascaded filler opfions were acceptable to the Shuttle Program. 
Processing GPS as a TAGAN measurement or filtering the GPS position vector could not have been 
evaluated in flight without actually incorporating the data into the navigation state. Both of fhese opfions 
would have required refuning fhe enfry navigafion Kalman fillers in fhe PASS and BPS flighf soffware. A 
new PASS flighf soffware Kalman filler for fhe orbifal phase of flighf would have fo be creafed. Any 
modificafions fo fhe exisfing fillers for enfry, or a new Kalman filler for orbif, would resulf in an exfensive 
flighf soffware developmenf and cerfificafion efforl. 


The Tightly Coupled Option 

In a fighfly coupled infegrafion, processing acfual GPS measuremenfs (pseudorange, della range) from a 
GPS receiver in a hosf vehicle compufer permifs fhe navigafion sysfem designer fo have more confrol 
over fhe qualify of fhe navigafion solufion, rafher fhan having fo rely on a receiver vendor's propriefary 
soffware. Processing high rale, unfilfered GPS observables and inerfial measuremenf unif dafa in a 
cenfral Kalman filler permifs higher accuracy navigafion and less vulnerability to GPS outages and 
jamming. This architecture enables rapid estimation of GPS receiver clock errors and inerfial 
measuremenf unif errors [86]. 

Processing of GPS pseudoranges in fhe PASS and BPS flight software was also considered, but not 
chosen. Like the cascaded filter options discussed previously, it would have required modifications to 
baseline entry navigation and a new Kalman filter for fhe on-orbif phase. Purfhermore, fhere were 
securify concerns wifh sending correcfed pseudoranges oufside fhe keyed GPS receiver fo fhe Shuffle 
GPGs. Uncorrecfed pseudoranges could be processed in fhe GPGs, buf fhe enfry and new orbif Kalman 
fillers would have fo solve for fhe corrupfion due fo Selecfive Availabilify. 
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state Replacement Chosen 


After considering eight integration options, the Shuttle Program directed that GPS be integrated "in 
parallel" with the existing baseline navigation on the orbiters. A GPS state (position and velocity) 
selected by the Shuttle flight software would overwrite the Shuttle flight software navigation state. "State 
replacement" in the Shuttle navigation software was chosen over treating GPS as a sensor and filtering 
the GPS measurements or state vector. This architecture treats the GPS receiver as a complete navigation 
system [1]. Any potential problems with cascaded Kalman filters would be avoided. State replacement 
could be implemented so that the same GPG flight software could be used for GPS processing during 
both orbit and entry. This was essentially the same integration architecture called for in a 1980 GPS 
upgrade proposal for the Shuttle. 

The Shuttle operates in a demanding flight environment with little margin for error. Shuttle software and 
hardware undergo an extensive test and validation process. Technical issues that arise before or during a 
flight can easily disrupt complex flight preparation schedules that span a period of years. The state 
replacement architecture lowered potential impact on the existing Shuttle navigation software, flight 
schedules and operations. GPS integration engineers also had to work within cost and schedule 
constraints and a desire to minimize hardware modifications to the vehicles. 

The integration architecture also allowed GPS receiver and Shuttle flight software GPS data collection to 
occur in the flight environment before certification, while still using the proven legacy navigation aids 
and Shuttle computer navigation algorithms [1]. This also permits operation of a "mixed fleet" of GPS 
and TAGAN hardware configurations with the same version of PASS and BPS flight software. Due to the 
schedule of orbiter overhaul periods, not all orbiters would be equipped with GPS units at the same time. 
Supported TAGAN/GPS configurations are (Figure 4): 

• Three TAGANs for operational use and one GPS receiver (single string GPS) for data gathering (test 
flights) or operational use. 

• Three GPS units for operational use and no TAGANs (three string GPS). 

• Three TAGANs and no GPS unit onboard. 

It was believed that this approach would also make it easier to upgrade the Shuttle with more advanced 
receivers, whereas the Kalman filtering of GPS measurements or vectors in the Shuttle GPGs might 
require retuning the filters in the GPG. Furthermore, if a receiver upgrade occurred, it was believed that 
this approach would eliminate the need for detailed knowledge of the GPS receiver's software. 

The GPS receivers are provided with position, velocity and attitude aiding from the Shuttle flight 
software (PASS, or BFS in the event of a PASS software failure). One aiding state vector is propagated 
for all three receivers, using selected IMU data from candidates that have been screened by a FDIR 
algorithm. The single aiding state is periodically reset with the Shuttle navigation state. 
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And Velocity 

“Single String” GPS Configuration 


GPS 

Receiver 


Aiding Data 

< 


> 

GPS Position 
And Velocity 



And Attitude Data 


“Three String” GPS Configuration 


FIGURE 4 - In the "single string" configuration, TACAN and GPS data may be processed 
concurrently. Microwave Landing System data takes priority over TACAN, GPS and 
barometric altimeter data. 

The PASS flight software subjects GPS state vectors to three Quality Assurance (QA) checks. The QA 
tests were designed so that retuning of the receiver Kalman filter, or changes to receiver residual edit tests 
would not be necessary for the Shuttle missionization. 


• A check of several receiver parameters, one of which is the Figure of Merit (FOM). 


• The current GPS state is compared with the receiver's previous state propagated to the current time. 


• Gomparison of the receiver states with each other. 


If criteria for any of the QA tests are violated, that receiver's state is not a candidate for selection. State 
vectors from candidate GPS units are then processed in a selection filter. The BFS flight software uses a 
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simpler QA and selection scheme than PASS. There are crew controls that allow these QA tests to be 
bypassed, if necessary. 

Once the QA checks are complete and a GPS state has been selected, there are two crew commanded 
methods for incorporafing fhe selecfed GPS sfafe info navigafion. The firsf involves aufomafic 
incorporafion af a flighf phase dependenf rafe, if fhe selecfed GPS sfafe is wifhin a folerance of fhe currenf 
navigafion sfafe. The second mefhod, called a "force," ignores fhe comparison fesf wifh fhe currenf 
navigafion sfafe and incorporafes (forces) fhe selecfed GPS sfafe info navigafion. 

Six years of fesf flighfs (1996 fo 2002) have proven fhaf fhe sfafe replacemenf archifecfure was fhe righf 
choice. Sfafe replacemenf permiffed fhe shuffle compufers fo conducf GPS QA fesfs and exercise fhe 
selection filler wifhouf using GPS as a primary source of navigafion dafa. If also allowed fhe feam fo 
avoid modifying fhe legacy enfry navigafion Kalman filler, which has proven ifself over 21 years (1981 fo 
2002) of operation. The Shuffle Program was able fo fly one sef of Shuffle software, regardless of fhe 
TAGAN and GPS hardware configuration, for as long as was needed, wifhouf commiffing fo use GPS 
operationally. 

Sfafe replacemenf also enabled Mission Gonfrol fo perform real-fime comparisons of fhe selecfed GPS 
vecfor wifh fhe Shuffle navigafion sfafe, wifhouf incorporafing GPS dafa info baseline navigafion. This 
addifional insighf will help assess fhe healfh of fhe onboard and ground-based legacy navigafion sysfems 
and resolve dilemmas befween legacy sensors. Had fhe feam chosen fhe cascaded filler archifecfure, if 
could have performed fhis assessmenf only in posf flighf simulafions fhaf processed selecfed position 
vectors in fhe onboard enfry Kalman filler. 


Receiver Selection 


During fhe early fo mid 1990s, use of Gommercial/Modified-Qff-The-Shelf hardware and software, and 

fhe "fasfer-beffer-cheaper" approach, were being sfressed wifhin NASA [90]. Use of an off-lhe-shelf 

receiver, and fhe success of GPS technology, was seen by some as fhe key fo a quick, low cosf Shuffle 

upgrade. For TAGAN replacemenf, fhe Shuffle Program desired an off-fhe-shelf, in producfion milifary 

unif designed for aircraft fo fake advanfage of fhe existing producfion line and logistics base. The Shuffle 

Program also desired fo be an aufhorized user of GPS, fo fake advanfage of fhe jamming and spoofing 

resisfance provided by milifary GPS Originally 

unifs. In addition, fhe Shuffle Program MAGR First am in uiow 

^ onm Enters MAGR ^H-ln-View jhree String 

2010 - n . , Receivers 

Production Flight on . .. , . 

For Military Shuttle 


wanted to benefit from software that 
had been matured through development 
and use by the Department of Defense. 
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A 1993 trade study selected a 5-channel 
aviation GPS receiver, the Miniaturized 
Airborne GPS Receiver (MAGR), which 
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Figure 5 - Receiver Selection Driven By Year 2000 Need Date 
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entered production in 1994 [91]. All-in-view military aviation receivers of this type did not become 
available until the late 1990s (Figure 5). The receiver tracking loops were digital, rather than analogue, 
and could be modified fo obfain measurements and download data at orbital velocities through software 
changes, rather than through changes to discrete electronic components, as was required with earlier 
receivers. The MAGR had several desirable capabilities, including authorized operation and the ability to 
accept inertial aiding data from an Inerfial Navigafion Sysfem (INS). A change fo fhe receiver power 
supply and inpuf/oufpuf elecfronics card was required fo make fhe receiver compafible wifh fhe orbifer 
power sysfem and dafa bus. Radiafion fesfing of fhe receiver af fhe Indiana Universify Cyclofron Facilify 
indicafed fhaf no hardware changes were required fo meef radiafion exposure requiremenfs. 

Exisfing space rafed GPS receivers were nof suifable for fhe Shuffle (i.e. didn'f accepf inerfial aiding from 
an INS, too big and heavy for fhe Shuffle, nof capable of aufhorized operafion). 


GPS Antennas 

Each GPS receiver uses fwo anfennas (Figures 6 and 7), which are mounted under fhe Shuffle fhermal 
profecfion sysfem, which does nof significanfly affenuafe fhe GPS signal. The anfennas provide direcf 
visibility of safellifes in any affifude while on-orbif or during enfry. The signal from each antenna is 
amplified by a pre-amplifier, fhen is passed fo a signal combiner fo provide one inpuf fo fhe receiver. 
Anfenna swifching is nof conducted. 

The single sfring MAGR/S flown during fhe fesf phase has fwo anfennas, one on fhe fop and one on fhe 
boffom of fhe crew comparfmenf (GPS 2 in Figure 6). Anfennas and cables used for fhe single-sfring 
configurafion were acfually insfalled in fhe Shuffles Discovery, Atlantis, and Endeavour when fhey were 
builf in fhe 1980s. For fhe fhree-sfring configurafion (Figure 6), anfennas for GPS unifs 1 and 3 occupy fhe 
former posifions of TAGAN anfennas (Figure 7). 


I nitial Flight Tests And Receiver Missionization 

The firsf flighf of a GPS receiver on fhe Shuffle was on mission STS-51 in September of 1993 [92]. A 
Trimble TANS Quadrex was flown. This experimenf was nof a parf of fhe TAGAN replacemenf projecf. 
The Quadrex was mounfed in an overhead window on fhe flighf deck. Signal affenuafion from fhe glass 
and limited field of view severely impacted receiver performance. 

The inifial flighf fesf program supporfing TAGAN replacemenf involved fhe 5 channel, Gollins 3M 
receiver. The 3M was a pre-producfion version of fhe Gollins MAGR. This series of flighf fesfs was 
intended fo prove if a GPS receiver designed for ferresfrial aircraff use could funcfion on fhe Space 
Shuffle wifh a minimum number of soffware changes. 
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Figure 6 - Three string GPS antenna configuration of Endeavour, circa 2005. 



Figure 7 - Three string TACAN and single string GPS antenna configuration 
0 ^ Atlantis anA Discovery, circa 2005. 

INS aiding was supplied to the 3M by the BPS GPC during ascent and entry, while on-orbit the receiver 
was unaided and operated by a laptop computer. Receiver state vectors and other 3M data were 
recorded on the laptop. The 3M was not keyed. Since the purpose of the 3M flight tests was purely data 
gathering, no navigation data was sent from the 3M receiver to the BPS GPC. The Collins 3M unit flew 
seven times (December, 1993 fo May, 1996) on Endeavor (flighfs 61, 59, 68, 67, 69, 72 and 77) (Table 1, page 
21, and Table 7, page 66). Modifications were made fo fhe 3M soffware befween flighfs based on flighf 
fesf resulfs. 

Hardware and soffware missionizafion of fhe Collins producfion MAGR for TACAN replacemenf began 
in 1995. The version of fhe MAGR flown on fhe Shuffle is known as fhe MAGR/S (MAGR/Shuffle). 
Collins based MAGR/S soffware on milifary MAGR Link 008, wifh Link 009 and 010 modifications also 
included. Lessons learned from fhe 3M flighfs were also incorporafed info fhe MAGR/S soffware. 


65 of 118 



"Single String" Tacan Replacement Flight Tests 


A single MAGR/S unit (the "single string" configuration, one MAGR/S and three TAGAN units) was 
flown on each orbifer during fhe flighf fesf and cerfificafion program for dafa collecfion (Table 7, Figure 

7). 


Table 7 - Shuttle GPS Test Flights For TACAN Replacement 


GPS 

Receiver 

Year 

Orbiter 

Shuttle Missions 

3M 

1993 

Endeavour 

61 


1994 

Endeavour 

59, 68 


1995 

Endeavour 

67, 69 


1996 

Endeavour 

72, 77 

MAGR/S 

1996 

Endeavour 

79 


1997 

Endeavour 

81, 82, 84, 85 


1998 

Endeavour 

89, 88 



Discovery 

91, 95 


1999 

Discovery 

96, 103 


2000 

Atiantis 

101, 106 



Discovery 

92 



Endeavour 

99, 97 


2001 

Ati antis 

98, 104 



Discovery 

102, 105 



Endeavour 

100, 108 


2002 

Ati antis 

110,112 



Coiumbia 

109 



Endeavour 

111, 113 


2003 

Coiumbia 

107 


2005 

Discovery 

114 


On many flights, a laptop computer was used to record instrumentation port data, in addition to receiver 
data normally transmitted to Mission Gontrol during a mission. This data greatly enhanced vendor 
efforts to track down and resolve complex software issues in the GPS receiver. After every flight, the GPS 
team examined fault logs. 


MAGR/S data was available in "real time" to Mission Gontrol personnel during ascent and entry. More 
flights followed as each orbiter in the fleet was equipped with a single MAGR/S receiver. STS-91 in June 
of 1998 was the first flight during which GPS data was available "in real time" to Mission Gontrol 
personnel during the orbital phase of flight. By the flight of Columbia on STS-109 in 2002, all four orbiters 
were flying with one MAGR/S receiver each, in the single string configuration. 


From STS-79 (September 1996) to STS-107 (January/February 2003), the Shuttle Program has accumulated 
-7,000 hours of MAGR nominal performance operating time from launch through landing. In 
comparison, -100 hours of TAGAN nominal performance operating time have been accumulated from 
Mach 10 through landing from STS-1 (April 1981) through STS-113 (November/December 2002). 
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GPS Tests 


Detailed Test Objectives (DTOs) were carried out during the single string flights. These tests involved 
astronaut execution of MAGR/S procedures. Selected MAGR/S state vectors were incorporated into the 
PASS and BPS flight software on several occasions while on orbit. On STS-103 (December 1999, before 
the deactivation of Selective Availability), the MAGR/S was intentionally unkeyed prior to entry. The 
Shuttle is certified to land with the MAGR/S unkeyed. Another DTO involved a late power-on of the 
MAGR/S just prior to entry on STS-92 (October 2000). This tested the ability of the MAGR/S to collect 
ephemerides, download the daily key and establish four satellite navigation during entry. 

Pre-Launch Ephemeris Collection 

The launch pad multi-path environment, obscuration of the lower antenna by the external tank, and non- 
optimal pointing of the upper antenna (boresight at the horizon) made pre-launch ephemeris collection 
difficult. This became a serious concern, as GPS may be required to support an emergency landing soon 
after launch. Simulation studies indicated that four hours were needed to collect GPS satellite 
ephemerides that would be needed for an emergency landing in Europe or North Africa. As GPS is 
powered on about five hours prior to launch, no changes were needed in the pre-launch time line. 

The team did not consider loading the receiver with ephemerides before liftoff using a data port and 
laptop computer. It would have been difficult to fit such a procedure into an already-crowded pre-launch 
timeline, and would have required orbiter hardware modifications to permit easy access to the GPS 
receiver from the crew compartment and an ephemeris verification procedure. 

Ascent Petformance Results 

For most of ascent, the Shuttle is in a heads down configuration. The GPS antenna on top of the crew 
compartment is facing the Earth, while the antenna below the crew compartment is facing the External 
Tank. In spite of the poor antenna visibility, enough GPS signals wrap around the External Tank and 
orbiter to permit the MAGR/S to track three to four satellites most of the time. However, the Geometric 
Dilution Of Precision (GDOP) is high, which can result in large state errors. On most flights, a roll to a 
heads up attitude is performed at about 6 minutes into the flight. This provides excellent GPS satellite 
visibility to the antenna on top of the crew compartment. Receiver tracking and performance during this 
phase of ascent is usually exceptional. 

On-Orbit Performance Results 

While on-orbit, noisy GPS velocity incidents (Figure 8) occurred that are consistent with the spatial (near 
the geomagnetic equator) and temporal (early evening to early morning) characteristics of ionospheric 
scintillation (Figure 9). Analysis has indicated that the velocity anomaly is induced by ionospheric 
scintillation of the phase of the GPS signals, which manifests in the delta-range measurements. Velocity 
noise as high as 11 feet per second has been observed and noise periods have lasted up to 20 minutes. 
Velocity noise was judged not to be a constraint for operational use of GPS by the Shuttle [93, 94]. 
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STS-88 GPS Velocity Noise (December 1998) 
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Figure 8 - Comparison of GPS velocity with Shuttle on-board navigation velocity, illustrating ionospheric scintillation 
induced velocity noise periods on three consecutive orbits. Bias is due to error in Shuttle on-board navigation state. 


On-orbit, GPS vectors did not permit orbit determination as accurate as that obtained with Mission 
Control processing of TDRSS and ground radar tracking data. This was expected, as the MAGR/S unit 
was not modified fo supporf high accuracy orbif deferminafion. Mulfi-pafh and upper anfenna 
obscurafion fhaf occurs while fhe Shuffle is docked fo fhe ISS degrades receiver performance, buf if does 
nof pose an operafional impacf. MAGR/S radiafion fesfing conducfed in 1997 indicafed fhaf no hardware 
modificafions were required. To dafe, no on-orbif anomalies have occurred fhaf could be fraced fo 
radiafion effecfs. 

Entry Petformance Results 

Receiver performance during fhe "blackouf" or "plasma" region of enfry was a concern (Figure 10). 
However, flighfs since 1993 have indicafed fhaf an inerfially aided, five-channel receiver can hack from 
one fo five safellifes during plasma, and a frue "blackouf" of GPS signals rarely occurs. Frequenf loss of 
lock and reacquisifion occur, along wifh less fhan opfimal GPS safellife geomefry. GPS sfafe vecfor errors 


68 of 118 








180“W 120“W eo^w 0“ 60“E 120°E 180T 



180“W 120“W 60“W 0” 60“E 120‘’E 180°E 


FIGURE 9 - Geographic distribution of ionospheric scintillation induced delta range noise for STS-99 
(February 2000), during the solar maximum. The geomagnetic equator and dip angle contours for ± 15 
and ± 45 degrees are indicated. 

during this period were not excessive. Lower antenna tracking can be impacted by plasma as high as 
320,000 feet, and the lower antenna may not resume continuous tracking until about 185,000 feet. The 
most severe plasma period impacts the upper anterma, and typically begins around 285,000, when the 
first roll maneuver occurs. Continuous upper antenna tracking of safellites typically resumes between 
220,000 feet and 200,000 feet. 

The impacts of fhe plasma region on fhe MAGR/S are extended periods of less fhan four safellife fracking, 
failed reacquisifion aftempfs, incomplefe data collection (i.e. ephemerides) and loss of delfa range 
measurements. Less than optimum number of measuremenfs and poor safellite geomefry could resulf in 
an increasingly inaccurate GPS state vector. However, navigation errors during the plasma region have 
so far nof been excessive. The orbiter can fly fhrough fhis region wifhouf an updafe from GPS. 

Roll maneuvers during enfry oufside the plasma region had little or no impact on receiver performance. 

Figure 11 depicts legacy entry navigation and selected GPS average +3 sigma position differences using a 
posf-flighf Besf Esfimate of Trajectory (BET) as fhe reference. The BET process blends Shuffle on-board 
dafa (IMU, MLS) with ground radar tracking, but does not include GPS data (GPS may be more accurate 
than the BET). Legacy navigation data is from 49 recenf Shuffle flights, while the GPS data used was from 


69 of 118 















Figure 10 - Receiver data from an altitude of 400,000 feet through landing. Figure of Merit (FOM) is the 
receiver's estimate of it's position accuracy. The Shuttle computers will not use GPS data if the FOM is 6 or 
greater. Geometric Dilution of Precision (GDOP) indicates how well the satellite geometry will enable the 
receiver to resolve navigation errors. The Less Than Four Satellite Tracking bit is "1" if less than four 
satellites are tracked. The plasma region for this flight was roughly from 260,000 feet to 210,000 feet. On 
most flights, FOM and GDOP typically have low values from the end of the plasma region through landing. 


12 single-string GPS test flights. The legacy navigation system, even at the 3-sigma level, is well within 
guidance constraints for maximum allowable navigafion error. GPS is considerably more accurafe fhan 
fhe legacy enfry navigafion sysfem. The 3-sigma keyed receiver accuracy specificafions for posifion are 31 
mefers horizonfal and 36 mefers verfical. The 3-sigma velocify specificafion is 0.1 mefers/second in bofh 
fhe horizonfal and verfical direcfions. 
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Figure 11 - Average ± 3-sigma position differences for entry legacy navigation and selected GPS using a post-flight 
Best Estimate of Trajectory (BET) as the reference. The BET includes ground radar and on-board (I MU and MLS) 
data, but does not include GPS data. Ground radar tracking begins between 160,000 and 150,000 feet, while MLS 
data processing begins around 17,000 feet. The gradual decrease in the BET versus GPS differences (particularly 
noticeable in down-track) is due to deceleration sensed by the IMUs, which improves BET accuracy. The plasma 
region (-270 to -220 kilo-feet) has little impact on receiver accuracy. Guidance constraints (heavy lines) represent 
the maximum navigation error under which guidance can still fly the Shuttle to a runway. 


Shuttle Software Changes 

Flight data from the MAGR/S as well as the GPC QA checks are examined both during and after 
missions. Flight tests and simulation results have driven changes to the MAGR/S software and PASS and 
BFS flight software that processes MAGR/S data. 

Flight experience also drove a change to the position and velocity vector-aiding scheme used by the PASS 
flight software. The original design involved propagation of a separafe aiding sfafe for each receiver. 
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with each propagator having an independent source of IMU data (i.e. an IMU is assigned to each 
receiver). Instead, one aiding state vector is propagated for all fhree receivers, using selecfed IMU dafa 
from candidafes fhaf have been screened by a FDIR algorifhm. Insfead of periodically resetting fhe 
aiding sfafes wifh each receiver's own GPS sfafe, fhe single aiding sfafe is periodically resef wifh fhe 
Shuffle navigation sfafe. The original design did nof perform a sanity check on the GPS states used to 
reset the aiding states in the PASS flight software. Resetting the single aiding state with the Shuttle 
navigation state takes advantage of profecfion provided by fhe GPS QA checks, fhe GPS sfafe selection 
process and fhe comparison of fhe selecfed GPS sfafe wifh fhe currenf navigation sfafe before GPS 
incorporation. The new aiding scheme also permifs fhe ground fo have more insighf info and confrol 
over fhe position and velocify aiding sfafes senf fo fhe receivers. 

GPS Availability 

The five channel MAGR/S uses four channels fo obfain navigation measuremenfs, and a fifth for 
ephemeris collecfion and safellife acquisition. New safellifes needed fo mainfain frack of an optimal sef 
of four are acquired sequentially. Under difficulf fracking condifions (mulfi-pafh, anfenna obscurafion, 
safellife line-of-sighf off of fhe anfenna gain pattern), mulfiple safellife swifches could fail or be delayed, 
resulting in less fhan optimal safellife geomefry or less fhan four safellife fracking for exfended periods of 
time. The receiver's esfimafe of ifs posifion accuracy could exceed a Shuffle compufer GPS qualify 
assurance fesf limif, which would prevenf fhe Shuffle compufers from using posifion and velocify dafa 
from fhaf receiver. A lack of GPS updafes during enfry could make if difficulf for fhe Shuffle fo reach fhe 
runway [84]. 

The Shuffle GPS feam conducfed an exfensive simulation campaign using a GPS receiver, fwo GPS signal 
generafors (one for each anfenna, upper and lower), and Shuffle enfry frajecfories, fo defermine whefher 
fhe GPS receiver could experience a loss-of-service for longer fhan 2.3 minufes befween an alfifude of 
140,000 feef and touchdown on fhe runway. A failure of any of fhe fesfs fo meef fhe loss-of-service limif 
would have necessifafed changes fo fhe receiver fo lower fhe probabilify of loss of service. Simulation 
resulfs indicated fhaf such changes were nof required. 


Status of Shuttle TACAN Replacement 

Delay in Certification 

The original flighf of fhree sfring GPS (no TAGANs) was planned for 1999. However, due fo fhe number 
of GPS software issues encounfered during flighf and ground testing, and a slip in fhe TAG AN 
decommissioning date (Figure 5, page 63, and Table 5, page 57), certification of Shuffle GPS for 
operational use was delayed by fhree years, from 1999 fo 2002. Additional receiver software versions, 
laboratory fesf campaigns and Shuffle fesf flighfs were scheduled. The projecf was reorganized fo 
enhance communication befween projecf parficipanfs, and fo improve idenfificafion, documenfafion and 
resolution of issues. The NASA independenf verification and validation confracfor audifed fhe MAGR/S 
software, which had been developed af governmenf expense. By March of 2002, all four orbifers had 
flown wifh one MAGR/S receiver insfalled for dafa collecfion, and for use in contingencies defined in 
Shuffle Program flighf rules. 
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Certification Status 


The MAGR/S and associated Shuttle computer software was certified for TACAN replacemenf in Augusf 
of 2002, over fhree years affer fhe original fargef dale. Uses for fhe single MAGR/S receiver configuration 
(Figures 4 and 6), in conjuncfion wifh TAGAN, on each orbifer were identified, and fhe receiver and 
associafed Shuffle compufer software was certified for fhese applicafions in December of 2002. 

TACAN Replacement on Endeavour 

On Ocfober 23, 2003, fhe Shuffle Program approved fhe removal of fhe fhree TAGAN unifs from 
Endeavour, and the installation of fwo additional MAGR/S receivers, bringing Endeavour fo fhe fhree- 
sfring GPS configurafion (Figure 4, page 62, and Figure 6, page 65). Once Shuffle flighfs resume, a ramp- 
up of increasing single sfring GPS use on Discovery and Atlantis in conjuncfion wifh TAGAN will be 
performed (Figure 7). These flighfs will lead fo Endeavour flying fhe firsf all GPS, no TAGAN flighf, 
which is expecfed fo occur in 2006. 

GPS On Discovery and Atlantis 

Bofh Discovery and Atlantis are equipped wifh one GPS receiver and fhree TAGAN unifs (Figure 4, page 
62, and Figure 7, page 65). During enfry, GPS dafa will be incorporafed info fhe primary and backup 
flighf compufers simulfaneously wifh TAGAN dafa. Since fhe TAGAN phase-ouf initiation dafe has 
slipped fo 2010 (2001 Federal Radionavigafion Plan), TAGAN availability is not considered to be a 
problem. Gontingent upon Shuttle Program direction, one or both of fhe orbifers may have their 
TAGANs removed and two MAGR/S receivers added as they cycle through the periodic Orbiter Major 
Modification activity. 


Mission Control And On-Board, Operational Use Of GPS By Flight Phase 

The following sections give an overview of fhe currenf Shuffle navigation mefhodology. Flow GPS sfafes 
will be used by fhe orbifer navigation sysfem and Mission Gonfrol affer MAGR/S cerfiticafion is covered. 

Pre GPS Ground Tracking 

Inifially, fhe Shuffle Program required confinuous fracking from 2 radars during ascenf and enfry, so fhaf 
Mission Gonfrol could defermine fhe Shuffle sfafe independenfly of fhe on-board navigafion sysfem. As 
confidence was esfablished in fhe on-board sysfem, fhe ascenf/enfry ground tracking requirement was 
changed from mandafory fo highly desirable. 

Prior fo launch, if fhere are cerfain failures on fhe vehicle, radar tracking to support navigation is 
required to meet Launch Gonstraint Griteria. G Band (range and angles) and S Band (range, Doppler, 
angles) radar data is processed in a Mission Gontrol based Kalman filter. The filter can process data from 
one S Band and fwo G Band radars. 
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If the Shuttle is to rendezvous with a spacecraft already in orbit (a "ground up rendezvous," such as with 
the International Space Station or Hubble Space Telescope), Mission Control checks the cross track 
velocity error after Main Engine Cut Off. A state vector update may be required prior to the OMS-2 
maneuver for cross-track velocity error greater than 6 feet/second. The uplink would be based on ascent 
ground tracking data processing. 

Initially, S Band communication sites provided tracking (range, Doppler, angles) during the orbital phase 
of flight, when the orbiter was visible. As TDRSS satellites were launched, ground S Band use for orbit 
was reduced. When available, TDRSS provides near global communications coverage, but only Doppler 
measurements due to the type of S Band transponder on the orbiter. 

On-orbit, both S Band TDRSS Doppler measurements; and C Band radar data (range and angles from a 
number of tracking stations) are processed to estimate the orbiter's state vector. The on-board navigation 
state is usually allowed to grow in down-track position error before a new state, based on radar and 
TDRSS tracking, is uplinked. For landing, the maximum allowable downtrack position error at Entry 
Interface (400,000 feet) is 20 nautical miles. 

TDRSS S Band Doppler tracking provides a good estimate of the orbital semi-major axis (which reflects 
both position and velocity). C Band tracking resolves planar errors. Radar geometry plays a large role in 
determining the accuracy of ground-based navigation. On-orbit, a weighted least squares algorithm is 
used by Mission Control for orbit determination. 

Ground-up rendezvous flights require radar tracking of the target spacecraft. Radar tracking begins from 
18 to 24 hours prior to Shuttle launch. Ground tracking of the target spacecraft continues through 
docking (ISS) or grapple (Hubble Space Telescope). If the orbiter deploys a scientific payload that is to be 
retrieved later in the mission, ground tracking of the deployed spacecraft will be performed to facilitate 
the rendezvous and grapple. 

For entry and landing. Mission Gontrol processes radar data in the previously mentioned Kalman filter 
for independent assessment of onboard navigation systems. Since Shuttle landings are plarmed for the 
Kennedy Space Genter (KSG), and radars are located there to support the Eastern Test Range, G Band and 
S Band radar tracking is usually available. G Band tracking is also usually available for landings at 
Edwards Air Force Base, since NASA has radars at the Dryden facility. However, range scheduling can 
prevent entry tracking. If there are certain failures in the on-board or ground navigation systems, radar 
tracking during entry becomes mandatory. 

During entry, radar normally becomes available in time for Mission Gontrol to assess the TAGAN units 
and navigation state health prior to TAGAN processing in the GPGs. Mission Gontrol can also perform 
an emergency state uplink to the orbiter if navigation errors are excessive. 
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Post GPS Ground Tracking 


After GPS certification, the Shuttle Program still considers radar tracking during ascent to be desirable, 
but not required, unless there are navigation equipment failures on the vehicle. 

Radar and TDRSS tracking will still be used during the orbital phase to support maneuver planning in 
Mission Control. The MAGR/S Kalman filter has not been tuned for orbital dynamics, since emphasis 
was on a TACAN replacement and a Commercial-Off-The-Shelf approach that minimized MAGR/S 
modifications. 

Shuttle Spacecraft Position Optimal Tracking (SPOT) Filter 

The MAGR Kalman filter and navigation algorithms were designed so that the unit could be integrated 
into a wide variety of atmospheric flight platforms without having to substantially modify the navigation 
algorithms to support specific integrations [95]. Filter tuning assumes a worst case inertial measurement 
unit and receiver clock. The downside to this approach is that the receiver is not optimized for space 
navigation. It effectively provides a blended deterministic solution without accurate gravity or drag 
modeling needed for accurate orbit determination. The performance of these algorithms is sufficient to 
support TAGAN replacement and Shuttle deorbit burns. 

However, MAGR/S velocity errors, and the resulting semi-major axis errors, render the receiver incapable 
of performing the high accuracy orbit determination currently performed with ground radar and TDRSS 
tracking to support post-insertion orbit assessment, orbit maneuver planning, debris avoidance analysis, 
and rendezvous. Poor orbital navigation performance of GPS receivers originally designed for terrestrial 
use and the importance of semi-major axis accuracy is covered by Garpenter and Schiesser [23]. 
Although the MAGR/S was modified by the Shuttle Program to improve velocity accuracy on-orbit, the 
improvement was insufficient to facilitate precision orbit determination. 

To take advantage of the near continuous availability of GPS state vectors from the Shuttle, a Mission 
Gontrol based filter, called Shuttle SPOT, was developed (Figure 12). Shuttle SPOT processes MAGR/S 
state vector data to provide an improved estimate of the orbit. MAGR/S data from Shuttle missions 88, 
96, 99, 106 and 108 was used to tune and certify the filter. Although a few technical issues arose, these 
were resolved and the development and certification of SPOT for the Shuttle was relatively 
straightforward. The filter will be certified for use after a flight following and evaluation phase over 
several Shuttle missions. 

Near continuous availability of ground filtered GPS state vectors, in conjunction with radar and TDRSS 
tracking, will allow more responsive mission planning. Burns will be confirmed more rapidly than with 
radar and TDRSS data alone. If the orbiter is subjected to perturbations that are not modeled by Mission 
Gontrol, it can take 2 or 3 revolutions before enough ground and TDRSS tracking data is available to 
quantify the impact on the orbiter state. SPOT will permit much more rapid perturbation determination. 
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Figure 12 - GPS vectors filtered by Mission Control will be used to 
support shuttle maneuver planning and debris avoidance. 


Ground radar tracking will be used on no-TACAN flights as a backup to GPS. TDRSS is also used for 
telemetry and communications, thus the Doppler measurements will always be available for processing. 
However, radar and TDRSS will still be designated as backups to GPS, and Mission Gontrol Genter 
personnel will maintain proficiency in G Band and S Band measurement processing. 

Pre-GPS Ascent And Post I nsertion 

Navigation aids (TAGANs, barometric altimeters, MLSs, radar altimeters) that would be used for an 
emergency landing due to an ascent abort are powered on and self tests are run prior to the day of 
launch. The three HAINS IMUs are calibrated and aligned before liftoff. Only HAINS IMU data 
(accumulated sensed velocity, gimbal angles) are processed by PASS and BPS navigation during powered 
flight [96]. No sensor measurements are processed by an on-board Kalman filter. 

Ascent And Post I nsertion I n The GPS Era 

There is no change to the Shuttle baseline navigation (use of HAINS IMU data) for powered flight. The 
MAGR/S units will be turned on approximately 5 hours prior to liftoff. This permits receivers to collect 
ephemerides of satellites that will be over the Trans Atlantic Landing (TAL) sites at launch. GPS states 
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are not used by the Shuttle navigation software during powered flight, but receiver aiding data is 
supplied to the MAGR/S units by the GPCs. 

After the GPS SPOT Filter is certified, if could be used as a source of posf Main Engine Guf Off sfafe 
vecfor uplinks. GPS vecfors from fhe on-board MAGR/S unifs would not be incorporated directly into 
navigation. 

GPS Metric Tracking For Range Safety 

The Shuttle Program examined the use of GPS for Space Shuffle range safely mefric fracking during 
launch, fo replace radars at the launch site. Radar replacement would have required the addition of GPS 
receivers, cables and anfennas fo fhe Solid Rockef Boosfers and Exfemal Tank. The orbifer GPS 
receiver(s) could nof be used as a source of range safely dafa, as fhey receive aiding dafa from fhe orbifer 
avionics sysfem and fherefore are nof an independenf source of sfafe vecfors. Even wifh a swifch fo GPS 
mefric tracking, G band radars would still be needed to support Space Shuttle operations. Radar tracking 
is highly desirable to support launch and emergency landings at the launch site soon after launch, to 
backup the Shuttle's onboard navigation system. Radar tracking is mandatory for landing if fhere are 
navigafion unif failures on fhe vehicle, and radar is needed fo supporf orbif deferminafion for 
rendezvous flighfs. In Ocfober of 2001, fhe Shuffle Program decided againsf a fransifion fo GPS mefric 
fracking for Space Shuffle range safely, as GPS mefric fracking infegrafion cosfs exceeded ownership and 
mainfenance cosfs of launch sife radars. 

Pre-GPS Orbit Coast Navigation 

During fhe orbif phase, fhe on-board navigafion sfafe is monitored and mainfained by Mission Gonfrol 
via sfafe vecfor uplinks. A venf force may also be uplinked by Mission Gonfrol for use by fhe GPGs. This 
fakes info account non-propulsive forces acting on the orbiter that cannot be detected by the HAINS 
IMUs, and reduces error growth in the on-board state. Vent values are based on flight history for specific 
orbifer affifudes. The orbifer stale (and for a rendezvous, fhe large! spacecraff sfafe) determined from G 
Band and S Band fracking are used by Mission Gonfrol for maneuver planning. 

Alignmenf of fhe HAINS IMUs is periodically performed using sfar sighfings [97]. Two sfar frackers 
wifh near orfhogonal lines of sigh! are locafed on fhe nose of fhe orbifers. Dafa from sfar sighfings can 
also be used by Mission Gonfrol fo defermine IMU gyro biases. The ground defermined biases are fhen 
uplinked for use in fhe Shuffle PASS flighf soffware. If fhe orbifer cannof maneuver fo a sfar sighfing 
affifude due fo excessive IMU misalignmenf, a rough alignmenf can be executed by a crew member 
sighfing on a sfar using fhe Heads Up Display (HUD) or fhe GO AS. This would be followed by a precise 
sfar alignment using the star trackers. 

Orbit Coast Navigation I n The GPS Era 

Current plans call for fwo of the three MAGR/S receivers to be powered off for mosf of the orbit period. 
MAGR/S state vectors will periodically be taken into the PASS flight software to maintain the on-board 
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navigation state accuracy at an acceptable level. Ground and TDRSS tracking will remain the primary 
source of state vectors for maneuver planning in Mission Confrol, unfil fhe GPS SPOT Pilfer is certified. 

There is no provision for GPS affifude deferminafion in fhe MAGR/S. Sfar sightings will still be used for 
precise HAINS IMU alignmenf. 

Pre GPS Rendezvous 

Successful rendezvous requires an accurafe relative sfafe for on-board burn fargefing and fargef frack 
affifude mainfenance. Relative velocify errors, in parficular, are critical. However, ground fracking of fhe 
orbifer and fhe fargef spacecraff is nof accurafe enough fo guaranfee a safe rendezvous wifhin fhe 
orbifer's tighf propellanf budgef. An on-board navigation sysfem fhaf provides an accurafe relafive sfafe 
is required. 

Shuffle rendezvous is divided info fwo phases, ground fargefed and on-board fargefed. For fhe ground- 
fargefed phase, fhe orbifer navigation sfafe is defermined by ground based radar and TDRSS fracking as 
described previously. Burns fo be execufed by fhe orbifer are compufed by Mission Gonfrol (hence fhe 
ferm "ground fargefed") and uplinked fo fhe vehicle for execution by fhe crew. The lasf ground fargefed 
bum is performed on fhe day of rendezvous, 40 naufical miles behind fhe fargef, af abouf orbifal noon. 
During fhe on-board fargefed phase (Figure 13), relafive sensor measuremenfs are processed in a Kalman 
filler in fhe PASS flighf soffware [98]. The PASS soffware mainfains an esfimafe of fhe fargef spacecraff 
sfafe (initially provided by Mission Gonfrol) and fhe tillered orbifer sfafe in an inertial frame. These 
sfafes are used fo compufe bum solutions using an onboard Lamberf fargefing algorifhm [99]. 

The sfar frackers used for IMU alignmenfs are also used fo process angular measuremenfs of fhe 
orbifer/fargef relafive sfafe. This permifs resolution of navigation errors normal fo fhe sfar fracker line of 
sighf. The sfar fracker pass begins shorfly after fhe lasf ground-fargefed maneuver, and will resolve mosf 
alfifude and ouf-of-plane position errors. Due fo change in relafive geomefry, some down-frack posifion 
error will be resolved af fhe end of fhe sfar fracker pass. The end of fhe pass roughly coincides wifh 
orbifal sunsef, and is followed by fhe firs! on-board fargefed maneuver. 

Incorporation of Ku Band radar measuremenfs begins af a range of 135,000 feel. Range, range rale and 
angular dafa are obfained from fhis poinf unfil a range of abouf 100 feel. Five more on-board fargefed 
bums are execufed fo confrol fhe orbifer's approach fo fhe fargef spacecraff. 

Af a range of approximafely 8 naufical miles, fhere is anofher opporfunify for a daylighf sfar fracker pass, 
in fhe evenf of a radar failure. Due fo fhe size and brighfness of fhe ISS, optical fracking during orbifal 
daylighf may nof be possible for fhis pass. A fracking lighf on fhe ISS facilifafes processing of sfar fracker 
dafa af nighf. The ISS maneuvers fo a nighf sfar fracker affifude af a predefermined time during fhe 
rendezvous. Such a failure occurred on STS-92 (Ocfober 2000), forcing execution of an "angles only" 
rendezvous. The rendezvous and docking was successful, buf wifh slighfly higher propellanf 
consumpfion. 
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1. NC, last ground 
targeted burn. 

2. Start star tracker 

3. End star tracker 

4. NCC, first on-board 
targeted burn. 

5. Start Radar 

6. Ti Burn 

7. Start star tracker 
(for radar fail) 

8. MC-1 Burn 

9. Sunset 

10. End star tracker 
for radar fail. 

11. MC-2 Burn 

12. Sunrise 

13. MC-3 Burn 

14. MC-4 Burn 

15. Manual piloting 
phase using radar, 
phase using radar, 
TCS & HHL. 


Axes are in kilo-feet 
NCC - Corrective Combination 
Ti - Transition initiation 
MC - Midcourse Correction 


Figure 13 - Day of rendezvous profile with burns and navigation activities indicated. Relative 
coordinate frame centered on the target spacecraft. "V Bar" is in the direction of target motion, 
"R Bar" is in the direction of the center of the Earth. 


If both the radar and star trackers are failed, the COAS may be used manually by the crew to obtain 
relative angular measurements. COAS measurements have never been taken in flight due to a sensor 
failure. However, after the undocking from Mir on STS-71 {Atlantis, June-July 1995), COAS data was 
processed as a test. 

After the final on-board targeted bum, at a range of about 2,000 feet, the manual piloting phase begins. 
Radar data continues to be incorporated into the orbiter navigation state during the manual phase, but 
the primary source of relative navigation data for piloting comes from the Trajectory Control Sensor 
(TCS). TCS is a laser system mounted in the payload bay that provides relative range, range rate and 
angular information. TCS requires retro-reflectors on the target vehicle. Two Hand Held Laser (HHL) 
range finders are also carried. Both TCS and HHL can lock on to the target as far out as 5,000 feet. 

A Kalman filter is used in the primary and backup laptop computers to process TCS measurements. 
HHL measurements are processed in the primary laptop, in a different Kalman filter than TCS. 
Television cameras in the payload bay, with ranging mler overlays on the monitors, are used by the crew 
as an additional range information source from 15 feet to docking. Ku Band radar, TCS and HHL are 
also used during undocking and fly-around, when the orbiter leaves the ISS. 
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Shuttle Rendezvous I n The GPS Era 


Even if both spacecraft have GPS units, simple subtraction of state vectors does not provide an accurate 
enough relative state for use in bum computation. Use of such data could easily result in an unsafe 
trajectory and an undesirable level of propellant consumption. 

Development of the on-board rendezvous navigation system for Apollo [99, 100] (on which the Shuttle 
system was based) proved that rendezvous could be accomplished with high inertial state errors on both 
vehicles, but low relative state errors [101]. High accuracy inertial states on both spacecraft are not 
enough to permit accurate rendezvous navigation. 

If GPS relative navigation were to be used for spacecraft rendezvous, identical GPS receivers on the target 
and chaser vehicles would be required. Processing of common satellite measurements from both vehicles 
in one Kalman filter permits the cancellation of common errors and biases (such as ionospheric error and 
Selective Availability) [102]. This in turn drives the need for a radio data link between the vehicles. 

The Space Shuttle Program had to preserve the capability to rendezvous with spacecraft that are not 
equipped with GPS units, such as the Hubble Space Telescope. The current suite of on-board, relative 
navigation sensors (radar, star trackers, lasers) provide relative states that are just as good as or better 
than the level of accuracy possible with relative GPS. 

Furthermore, the International Space Station requirements for GPS were limited to coarse orbit 
determination to support pointing of antennas to the TDRSS satellites. Obscuration of GPS signals by ISS 
stmcture and multi-path would pose a significant problem for relative GPS in close proximity to the 
station. The Shuttle Program currently has no plans to use relative GPS for rendezvous. 

Pre-GPS Deorbit 

Gurrently, a state vector uplink is performed prior to the deorbit burn to both the PASS and BPS flight 
software. This uplink is based on Mission Gontrol processing of ground radar G Band and TDRSS S Band 
data. 

Deorbit I n The GPS Era 

The current operations concept calls for the three MAGR/S units to be operating 6 hours prior to the 
deorbit burn. Selected MAGR/S data will be incorporated into the Shuttle navigation software prior to 
the burn, replacing the uplink from Mission Gontrol. As with ascent and orbit insertion, MAGR/S data 
will not be incorporated into navigation during powered flight. 

Pre-GPS Entry Navigation 

For most of entry, three independent navigation states are maintained in the PASS [103]. Each uses 
accumulated, sensed velocity data from a different IMU to protect against IMU failures. A selection filter 
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selects one navigation state (position and velocity) for use in the Kalman filter. It is also passed on to 
guidance, flight control and crew display functions. 

The first navigation filter measurement to be processed is called "drag altitude." Measurement 
incorporation begins when the IMU sensed deceleration is greater than 11 ft/sec^ (Figure 14). 
Accumulated sensed delta velocity data from fhe IMUs are used fo esfimafe afmospheric densify. A mafh 
model of fhe afmosphere fhen provides a rough esfimafe of alfifude. Drag alfifude measuremenfs are 
rafher inaccurafe, buf are infended fo bound error growfh in fhe evenf of ofher navigafion sysfem 
failures. 



Figure 14 - Availability of navigation sensors and systems during entry. BFS does not process 
MLS, but processes TACAN and Baro all the way to landing. Radar altimeter data is for crew 
situational awareness only. Ground tracking (radar) data is used by Mission Control for 
independent assessment of onboard navigation systems. 

Kalman filter processing of selected TACAN range and bearing measurements begins at a range no 
greater than 400 nautical miles from the runway and an altitude of roughly 140,000 feet (for a nominal 
entry and landing). TACAN bearing is not processed when the elevation angle of the slant range is 35 
degrees or greater (cone of confusion). 

Significant navigation errors during entry can exceed the ability of the guidance and flight control system 
to fly the orbiter to the landing site. A set of limits, called guidance constraints, defines the maximum 
allowable state error. In the event of a navigation error that exceeds the constraints, a correction to the 
state vector can be uplinked directly to the PASS and BFS flight software or voiced to the crew for manual 
entry. The "delta state update," which is based on radar tracking data, has never been executed in flight. 


81 of 118 




Barometric altimeter measurements are processed to control navigation errors in the vertical channel. 
Two barometric altimeter probes are deployed at Mach 5, and data becomes available for Mission Control 
evaluation at Mach 3.5. Each probe provides two independent measurements. Kalman filter processing 
begins at Mach 2.5 and an altitude of abouf 85,000 feef. Drag alfifude processing ends once baromefric 
alfimefer processing begins. Baromefric alfimefer processing is inbibifed befween Mach 1.6 and Mach 1.1 
(fhe Mach jump region). 

PASS Kalman filler processing of MLS range, azimufh and elevation dafa usually begins af abouf 17,000 
feef. Once MLS is acquired, PASS slops processing TACAN and baromefric alfimefer dafa and shifts 
from mainfaining fhree sfafe vecfors fo one sfafe vector. For a landing sife nof equipped wifh MLS, PASS 
processing of TACAN slops af an alfifude of 1,500 feef, and baro processing confinues unfil 500 feef. BPS 
does nof process MLS, and will process TACAN and baro dafa all fhe way fo landing. 

Selected radar alfimefer dafa is available fo fhe crew for sifuafional awareness from 5,000 feef unfil 
landing. If is nof processed in a Kalman filler, due fo a lack of accurafe terrain models for Shuffle landing 
sites. 

Emergency Use Of Uncertified, Single String GPS During Entry 

During fhe flighf fesf phase (prior fo fhe Augusf 2002 cerfificafion, only one MAGR/S on each orbifer), 
flighf rules were developed permiffing use of selecfed MAGR/S sfafe vecfors under fhe following 
emergency conditions: 

• Use in place of a voice della sfafe uplink during enfry. Complexify of fhe voice della sfafe uplink 
makes if more risky fhan incorporating uncerfified GPS dafa. 

• Avoid scenarios (low ceilings af landing, on-board and/or ground sfafion TACAN and MLS failures) 
fhaf could resulf in a high-risk crew bailouf and loss of vehicle. 

• Enable Mission Confrol fo resolve dilemmas befween redundanf navigation sensors (HAINS IMUs, 
baromefric altimeters, TACANs, MLSs). This does nof require incorporafing GPS slates info fhe Shuffle 
navigation software (Figure 15). 

During framing simulations. Mission Gonfrol framing supervisors regularly fail various sysfems on fhe 
Shuffle fo frain flighf confrollers on anomaly recognition, resolution, and procedural work-arounds. 
Failing a navigafion sensor involves eifher presenting fhe Shuffle compufers wifh erroneous dafa fhaf 
prevenfs fhem from using fhe sensor or simply fuming off fhe unif. Simulation experience in Mission 
Gonfrol has proven fhaf a single functioning GPS receiver greafly aids flighf confrollers in identifying and 
isolafing suspecf legacy navigafion unifs. Regularly failing fhe GPS receiver prevenfs flighf confrollers 
from becoming foo dependenf on GPS for anomaly identification and resolution. 
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Figure 15 - The Shuttle GPS single string (one GPS receiver) configuration greatly 
aids detection and isolation of suspect legacy navigation sensors by Mission Control. 


Entry Navigation I n The GPS Era 

For the first several operational flights, selected MAGR/S data will not be taken into the Shuttle 
navigation software between the deorbit burn and the acquisition of ground radar fracking (around 
140,000 feef, the TACAN acquisition altitude). This will permit a comparison of MAGR/S data with 
ground tracking before incorporafion. Once operafional experience wifh fhe fhree string system has been 
obtained, navigation system updates with GPS will resume after the deorbit burn and continue through 
MLS acquisition (or landing if MLS is nof available). However, selected MAGR/S states do not have to be 
continuously incorporated into Shuttle navigation to support entry and landing. 

Drag altitude measurements will still be processed to bound error growth in the event of GPS oufages or 
IMU failures. It is expected that drag measurements will have little impact on the navigation state when 
GPS is incorporated in the automatic mode. 

Space Shuttle navigation software will continue to process barometric altimeter and MLS data (in the 
PASS) after TAGAN has been replaced by GPS. Whenever selected barometric altimeter measurements 
are available for processing by fhe PASS and BFS GPGs, fhey will also be processed by the MAGR/S 
Kalman filter. This allows the GPS units to determine the bias on the barometric measurements during 
four safellife fracking. In fhe evenf of less fhan four safellife fracking, calibrafed baromefric alfimefer 
measurements will help maintain accurate MAGR/S states. 

GPS states will be an important source of dafa for Mission Gonfrol during emergency landings af sites 
where there is no ground radar tracking capability. 
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During entry. Mission Control in Houston will have an open line to the GPS Master Control Station 
(MCS) at Schriever Air Force Base, Colorado. Mission Control will be informed of any GPS safellife 
infegrify issues fhaf arise. The crew has fhe ability to command the MAGR/S units not to track specified 
GPS safellifes for measuremenfs. 

Single-String GPS Use After Certification 

The single GPS receivers on Discovery and Atlantis will be used as a navigation source during enfry, buf 
TACAN dafa will continue fo be processed. This will enhance safely of flighf and provide crew and 
Mission Confrol personnel wifh operational experience and confidence building in GPS before fhe use of 
fhree siring GPS on Endeavour. Posf certification, single siring use of GPS during enfry has been 
proposed as follows: 

• Those scenarios lisfed under emergency use of uncertified, single-sfring GPS. 

• Use as an exfra level of redundancy in case of TACAN navigation sensor and/or ground sfafion failures 
(TACAN, radar). 

• Provide redundancy in fhe even! of ground radar fracking sfafion failures. 

• Avoid early mission fermination due fo TACAN failures while on-orbif. 

• Source of vectors fo supporf emergency deorbif. 

• On-board navigation updates on-orbif, when nof performing franslafional maneuvers or rendezvous. 

• Permif a launch in fhe even! of a navigation aid (TACAN, baromefric altimeter, MLS) failure on fhe 
pad. 

The single-sfring configuration also provides additional profecfion when using TACAN sfafions of 
questionable calibration af emergency landing sites. TACAN sfafions used by fhe Shuffle for landings af 
fhe Kennedy Space Cenfer, Edwards Air Force Base, and Norfhrup Strip (New Mexico) are calibrated to 
tighter NASA standards. Emergency landings at other sites, in the United States and around the world, 
require use of TACAN sfafions fhaf have been calibrafed fo sfandards fhaf are nof as tighf. Single-sfring 
GPS will provide more accurate navigation af fhese sites fhan TACAN, and if is fhe technique fhaf 
Mission Confrol prefers. TACAN will still be available in fhe evenf fhe Shuffle compufers cannof use 
single-sfring GPS dafa. 

Operational Ramp-Up to Single String Use During Entry 

The operafional ramp-up fo use of single sfring GPS during entry will occur over five flighfs sfarfing after 
fhe refurn fo flighf {Discovery, STS-114, July-Augusf 2005). The poinf on each flighf af which GPS 
incorporation will begin is defined: 
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1. GPS to BPS after radar acquisition (-140,000 feet, - Mach 6). 


2. GPS to the BPS after the deorbit bum. 

3. GPS to PASS after radar acquisition (-140,000 feet, - Mach 6). 

4. GPS to PASS after the deorbit burn. 

5. GPS to PASS and BPS after the deorbit burn. 

Operational ramp-up for single sfring use should be complefe before fhe firsf flighf of fhree-sfring GPS 
(no PAGAN) on Endeavour. 

Differential GPS and the Space Shuttle 

Alfhough fhe MAGR/S does have a differential GPS capabilify, fhere are currenfly no plans fo replace 
MLS wifh differential GPS. Use of a MAGR/S fo perform differential GPS, and replace fhe Microwave 
Landing Sysfem, was discussed, buf nof pursued due fo the continued viability of MLS, and fhe difficulty 
of using fhe five-channel receiver to support the differential application. Studies have shown that 
differential GPS would provide little accuracy improvement over the current MLS system. 

A differential GPS capability would have required adding Very High Prequency (VHP) antennas to the 
orbiters, with adequate visibility to support landing, as is done with PAGAN antennas. After PAGAN 
replacement, the GPS antenna pairs would occupy two of fhe positions formerly occupied by PAGAN 
anfenna pairs. Phere are fechnical issues wifh placing omni-direcfional VHP anfennas under fhe fhermal 
profecfion files in spofs formerly occupied by Ku Band MLS anfennas. New anfenna posifions and 
associafed holes in fhe orbifer sfructure for cabling would have been required for fhe VHP anfennas. 
Drilling more holes in fhe vehicle for anfenna placemenf is nof desirable. 
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8. Other GPS Receivers On The Space Shuttle 


Several civilian GPS receivers have flown in the Shuttle payload bay in support of experiments and on 
deployed payloads (Table 1, page 21). 


Relative GPS Demonstrations 

Perhaps the most notable were relative GPS navigation experiments conducted on two Shuttle missions 
that deployed and retrieved scientific payloads. These experimenfs were infended fo invesfigafe fhe use 
of GPS for spacecraft rendezvous. One was conducfed joinfly wifh fhe European Space Agency as a risk 
mifigafion efforf in supporf of fhe Aufomafed Transfer Vehicle under developmenf for fhe ISS Program. 
Flighf resulfs may be of imporfance fo fufure developmenf of relative GPS fillers for rendezvous and 
formation flying. 

On STS-69 {Endeavour, Sepfember 1995) [12,14,15] fhe Wake Shield Facilify (WSF) free flyer had an Allen 
Osborne TurboSfar GPS receiver. The orbifer Endeavour was equipped wifh fhe Gollins five channel 3M. 
The Orbiting Refrievable Far and Exfreme Ulfraviolef Specfromefer Shuffle Pallef Safellife (ORFEUS- 
SPAS) payload deployed and lafer refrieved on STS-80 {Columbia, November-December 1996) was 
equipped wifh Laben Tensor (nine channel) and Acfel GPS receivers [13]. The source of orbifer dafa 
during STS-80 was a Trimble Advanced Navigation Sysfem (TANS) Quadrex (six channel) receiver. 

GPS pseudorange dafa from receivers on fhe deployed payloads and fhe orbifers were processed in 
laptop computers on fhe Shuffle during fhe flighf, and on fhe ground bofh during and posf-flighf. The 
lapfops confained Kalman filters fhaf provided a relative navigation solution. 

During fhe STS-69 fesf, poor safellife visibilify resulted in few periods where bofh receivers were fracking 
a sef of four common safellifes needed for accurate relative navigation. Alfhough a power supply failure 
in fhe TurboSfar prevenfed relative navigation during fhe rendezvous, dafa was available from ofher 
periods of WSF acfivify. Lessons learned from STS-69 dafa processing were applied fo fhe STS-80 relative 
navigation experimenf developmenf [15]. 

On STS-80, fhe SPAS affifude during fhe approach of fhe Shuffle was confrolled so fhaf GPS antennas on 
bofh vehicles would see fhe same safellifes. This helped facilifafe common fracking of af leasf four 
safellifes. In-flighf and inifial posf-flighf resulfs were less fhan safisfacfory due fo issues involving 
receiver clock drift, frequenf acceleration from Shuffle jef firings, unmodeled acceleration compensation, 
residual edif fhresholds and an error in fhe anfenna fo center of gravify offsef compufafion. Beffer 
performance was obfained after fhe relative filter and measuremenf processing was modified after the 
mission [13]. Relative position accuracy was comparable to Shuttle on-board relative navigation 
performance, buf fhe relafive velocify performance was poor compared fo fhe Shuffle. Processing of 
carrier phase measuremenfs would have improved relafive GPS velocify. 
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Lack of insight into the 3M, TurboStar, Tensor and Quadrex GPS receivers made integration, data 
processing and data analysis more difficult. In addition, lack of insight into algorithms (particularly 
those associated with clock steering) made development of the laptop based relative GPS navigation filter 
more challenging. 


Scientific Payload Support 

The flight of Endeavour on STS-99 in February of 2000 carried the Shuttle Radar Topography Mission 
(SRTM) payload. Two Blackjack receivers (which were originally designed for space applications) on the 
payload provided GPS data to be processed post-flight to provide highly accurate positioning data [17]. 
Due to the critical nature of the mission. Shuttle MAGR/S, TDRSS Doppler and Shuttle IMU data served 
as an independent back-up to the Blackjacks. A spare MAGR/S was carried on the flight in a mid-deck 
locker and an in-flight MAGR/S change-out procedure was developed for the crew in the event that the 
primary MAGR/S failed. The Blackjack met the 60 cm position accuracy requirement needed for post¬ 
flight processing of SRTM data. 


Preparation for Future Autonomy Demonstration 

The Low Power Transceiver (LPT) flew in the cargo bay of Columbia on STS-107 [104-106]. A 
collaborative effort between NASA and industry, the LPT demonstrated both GPS navigation and 
communication capability through TDRSS and the Space Tracking and Data Network (STDN). The 
NASA Goddard developed GPS Enhanced Orbit Determination Experiment (GEODE) software [107] was 
used in the LPT to provide high accuracy orbit determination. Data was downlinked during the mission 
for evaluation. Future applications of the LPT include autonomous navigation, spacecraft 
communication, range safety for space based ranges and satellite formation flying. 
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9. Shuttle Space I ntegrated GPS/1 NS 


As GPS receivers became smaller, navigation system developers began envisioning the placement of GPS 
receivers directly inside Inertial Navigation System (INS) units, which themselves contain an Inertial 
Measurement Unit. By 1995, Embedded GPS/Inertial Navigation System (or "Embedded GPS/INS" or 
"EGI") units entered production for afmospheric flighf and ferresfrial applicafions. The EGI provides 
cost, size and weight savings over previous navigation systems which consisted of separafe avionics 
boxes. Since GPS dafa would nof have fo be senf oufside fhe receiver fo be processed, a cenfral Kalman 
filler could incorporafe GPS measuremenfs corrected for S/A effecfs, as well as ofher measurements 
(barometric altimeter, Doppler radar, radar altimeter). 


Tightly Coupled I ntegration 

The tightly coupled integration scheme of the EGI overcomes data latency issues with previous 
architectures. Less latency in aiding permits the carrier loops to be aided and speeds up satellite 
acquisition. The incorporation of all sensor measuremenfs in one filler wifh high infegrafion rales 
provides a much more accurafe solufion fhan separafe box archifecfures. In addifion, ground and flighf 
fesfing has shown fhaf fhe fighfly coupled EGI blended solufion has far superior performance under less 
fhan 4 safellife fracking condifions fhan a sfand alone GPS receiver [86]. Since an aircraff or missile is 
subjecfed fo confinuous specific force (due fo thrusf, liff and drag), fhe Kalman filler can obfain esfimafes 
of sensor errors as maneuvering makes sensor errors visible fo fhe filler fhrough posifion and velocity 
errors. Gontinuous calibration of fhe inertial sensors permifs an accurafe posifion, velocity and attitude 
solution during GPS outages (such as jamming). This also allows manufacturers to use lower cost inertial 
sensors. The Kalman filter also permits alignment of inertial sensors much fasfer fhan INS sysfems 
wifhouf GPS [108]. These facfors, along wifh cosf, size, power and weigh! savings made EGI unifs an 
attractive alternative to legacy navigation systems consisting of multiple line replaceable unifs. 

Three fesf flighfs of EGIs were conducfed to determine if such a device could be used in space wifh a 
minimum number of software modifications (Table 1, page 21). The firs! EGI unif fo fly was fhe Liffon 
LN-IOOG, wifh a Gollins GEM III five channel SEM-E form facfor GPS receiver. The GEM III confained 
software modified for space use, based on GEM III Link 010, produced by Gollins fo supporf fhe Army 
Tactical Missile Sysfem program. The Liffon EGI flew on missions STS-81 {Atlantis, January 1997) and 
STS-86 {Atlantis, Sepfember-Ocfober 1997) fo provide dafa gafhering for NASA's X-33 and X-34 programs. 
A Honeywell H-764G EGI, wifh fhe same fype of GEM III receiver as was flown in fhe Litfon unif, flew 
on STS-84 {Atlantis, May 1997). 


Shuttle Space I ntegrated GPS/1 NS 

In Sepfember of 1996, Honeywell was awarded a confracf by NASA for fhe Space Infegrafed GPS/INS, or 
SIGI. SIGI was to be a common NASA navigator, based on the H-764G EGI, to be used by both manned 
and unmanned space vehicles [3]. The Shuttle version of SIGI, infended fo replace fhe MAGR/S and fhe 
HAINSIMU, confained fhe same Gollins GEM III GPS receiver fhaf was previously mentioned. 
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Whereas the MAGR/S was integrated into the Shuttle avionics system as a "navigation system," the 
Shuttle SIGI was to be integrated as both a sensor and a navigator. The SIGI blended state vector solution 
was processed by the Shuttle PASS and BPS flight software using the same software used to process 
MAGR/S data. GPS receiver data and control commands were kept the same as MAGR/S. This 
integration concept was known as "MAGR/S transparency," and minimized the amount of changes fo fhe 
Shuffle flighf soffware. 

The Shuffle flighf soffware requires a source of IMU dafa (infegrafed affifude rafes, change in 
accumulafed sensed velocify). SIGI infegrafed affifude rafes and change in accumulafed sensed velocify 
dafa were fo be processed by fhe PASS and BPS compufers as sensor dafa, in fhe same way fhaf PIAINS 
IMU dafa were processed. 

The original inerfial sensor infegrafion concepf was "PiAINS IMU fransparency," an affempf fo avoid 
changes fo fhe Shuffle flighf soffware. The SIGI sfrapdown inerfial insfrumenf dafa was fo be processed 
wifhin fhe SIGI fo look like sfable member PiAINS IMU dafa, before being passed fo fhe PASS and BPS 
GPGs. Plowever, fhe fransparency opfion would have made if impossible for Mission Gonfrol fo idenfify 
and fake acfion on suspecf gyros and acceleromefers. As a resulf, fhe PIAINS IMU fransparency opfion 
was abandoned. More changes were made fo fhe SIGI soffware fo supporf fhe Shuffle missionizafion 
fhan were expecfed. 

The sfable members of fhe fhree PIAINS IMUs are skewed wifh respecf fo each ofher, so fhaf Mission 
Gonfrol personnel can idenfify suspecf gyros and acceleromefers if only fwo PIAINS IMUs are operafing. 
Wifh fhe sfrapdown configurafion of fhe SIGIs, fhe axes of fhe inerfial insfrumenfs in all fhree SIGI unifs 
would be parallel, making if difficulf for Mission Gonfrol fo idenfify suspecf inerfial sensors if only fwo 
SIGIs were operafing. Mounfing fhe sfrap-down SIGI unifs in a skewed configurafion was nof feasible; 
fherefore four SIGI unifs on each orbifer were needed. As a resulf, plans were made fo carry four SIGIs 
on fhe orbifers, rafher fhan fhree. 


Shuttle SI Gl Ground and Flight Test Results 

SIGI radiafion fesfing resulfed in fhe replacemenf of a sfafic random access memory chip. Shuffle SIGI 
flew on Shuffle missions 86, 89, 91, 95, 88, 96 and 103 from Sepfember of 1997 fo December of 1999. A 
cable splitter after fhe radio-frequency combiner enabled fhe SIGI fo use fhe same anfennas, pre-amps 
and combiner as fhe MAGR/S. SIGI commanding and dafa recording was conducfed by a crew operafed 
laptop computer. Numerous changes were made fo SIGI soffware based on ground and flighf fesf 
resulfs. Glosed loop lab fesfing of SIGI unifs using a signal generafor fhaf involved bofh fhe GPS and 
IMU funcfions of fhe devices was challenging. 

During frequenf flighfs of milifary aircraft fhe maneuvering, confinuous specific force (engine fhrusf, lift 
and drag) and processing of GPS measuremenfs permifs fhe EGI Kalman filler fo accurafely calibrate fhe 
gyros and acceleromefers. While fhe SIGI sfrapdown IMU dafa was reliable, blended filter performance 
was frequenfly quesfionable and much of fhe soffware modification efforf was aimed af fhe blended 
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filter. The short periods of flight during which the shuttle experiences specific force (lift, thrust and drag) 
while maneuvering (ascent and entry), coupled with months between flights rendered the reliability, 
stability and quality of blended Kalman filter inertial sensor error estimates doubtful. 

For the Shuttle to get into a precise orbit the IMUs must be accurately aligned on the launch pad. Stable 
member HAINS IMUs are aligned by using the sensed Earth rotation and gravity direction. The platform 
is oriented in various directions so that each of the accelerometers can calibrate against the gravity vector 
and the gyros can calibrate against Earth rotation. With all of the advantages of a space missionized EGI, 
preflight strapdown system alignment presented a challenge. There were three opportunities at the 
Kennedy Space Center to make observations when the vehicle was at different orientations: the Orbiter 
Processing Facility, the Vehicle Assembly Building, and the launch pad. The difference in orientation at 
the three locations was not adequate to get a good separation of the alignment variables. 

Since the FIAINS IMUs were projected to be operational through 2010, replacement of the FIAINS IMUs 
and MAGR/S units by SIGIs was deferred, and the project was placed on the shelf after the STS-103 test 
flight {Discovery, December 1999) was conducted. 
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10. X-38/ Crew Return Vehicle 


In the mid 1990s, NASA JSC began to develop the X-38, a prototype of a proposed CRV for fhe 
International Space Station. The CRV was to provide an emergency return capability for fhe ISS crew in 
fhe evenf of a medical or spacecraff emergency. GPS was a key parf of fhe X-38 avionics sysfem [2]. 
Alfhough fhe X-38 projecf was canceled in fhe spring of 2002, much GPS work was performed and 
imporfanf lessons were learned. 


V-201 Flight Test 

Af fhe time of projecf cancellation, the X-38 team was preparing the V-201 vehicle for an unmanned fesf 
flighf. This fesf involved V-201 deploymenf from fhe Shuffle payload bay using fhe Remofe Manipulafor 
Sysfem, followed by execution of a deorbif, enfry and landing profile. V-201 would have been equipped 
wifh three SIGI units (to meet the one fault tolerant requirement). The operational GRV (human rated), 
which would have been taken to the ISS on a later Shuttle flight, was to have had four SIGIs (fo meef fhe 
fwo faulf toleranf requiremenf). 


X-38 Design 

To lower developmenf costs, the X-38 used the same outer mold line as the Martin Marietta X-24A lifting 
body, which was tested from 1969 to 1971 (Figure 16) [109]. The lifting body had a higher lift to drag 
ratio than a lifting capsule (such as Apollo, Soyuz, and Gemini), and therefore provided a less sfrenuous 
entry (i.e. lower g forces), which is an imporfanf consideration when returning injured or sick 
crewmembers from orbif. A lifting body also provided more enfry cross and downrange maneuvering 
capabilify fhan a tiffing capsule, which enhanced fhe abilify of the GRV to quickly return a crew to an 
appropriate landing site. Rather than a high speed landing on a runway, as was done by the lifting 
bodies tested at Edwards from 1963 fo 1975, a 5,500-square foof steerable parafoil was used (Figure 17). 
Elimination of runway landing also lowered developmenf cosfs, and increased fhe number of possible 
ground landing sifes, which in fum reduced fhe time required to return crewmembers from fhe ISS [110]. 



Figure 16 - The Martin Marietta X-24A at 
Edwards Air Force Base, 1968. 
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CRVGPS Unit 


The X-38 used the same type of SIGI unit and Force 19 GPS 
receiver as the ISS, but some changes to the X-38 SIGI 
software were made later in the program. However, unlike 
the ISS SIGI, the strapdown IMU measurements and 
blended filter data were required from the begirming. 
High accuracy IMU data was critical for performing guided 
lifting entry at hypersonic velocities to achieve a precision 
landing. The Force 19 would provide the same position, 
velocity and attitude data as was done for ISS. Leveraging 
on fhe ISS GPS affifude developmenf efforf would lower 
developmenf and infegrafion cosfs. GPS affifude 
defermination was also believed fo be a less cosfly solution 
fo fhe initial affifude defermination problem fhan sfar 
frackers, which would require modification fo fhe X-38 
sfrucfure. Four GPS anfennas were placed on fhe top of fhe 
X-38 to support attitude determination (Figure 18). 



Figure 17 - X-38 prototype V-132 
during the fifth drop test at 
Edwards, March 2000. 


Four Upper GPS 



Figure 18 - X-38 GPS antennas and camera bore sights for the proposed V-201 
unmanned test flight. Only camera bore sights in the plane of the figure are shown. 
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CRV SI Gl Ground and Flight Testing 


Drop Tests 

Prototype X-38 vehicles were dropped from a 
NASA B-52B at Edwards AFB to test the landing 
guidance, navigation, control, and parafoil 
systems (Figure 17) [110]. These vehicles used the 
H-764G EGI unit intended for atmospheric flight, 
rather than the SIGI (space) version of fhe H-764G 
(Figure 19). The EGI integration and operation on 
the X-38 was smoother than the GRV SIGI 
integration, as the EGI was being used in an 
atmospheric application, for which if was 
originally designed. 

Test Flights on the Shuttle 

The GRV SIGI flew in a data collection mode on tv 
the radio-frequency combiner enabled the SIGI to use the same antermas, pre-amps and combiner as the 
Shuttle MAGR/S. Attitude determination was not exercised. Examination of GPS satellife fracking by fhe 
MAGR/S and GRV SIGI unifs on Shuffle flighfs also led fo fhe addifion of fhe lower anferma on fhe X-38 
(Figure 18). Having bofh upper and lower GPS anfennas (as was done for fhe Shuffle MAGR/S receivers 
and the legacy Shuttle TAGAN units. Figures 6 and 7, page 65) facilitated successful fracking af all 
affifudes on-orbif and during enfry when nof in fhe plasma region. 


Table 7 - X-38 SIGI Flight Test Program on the Shuttle 


Shuttle 

Mission 

Year 

Orbiter 

Primary Mission 

100 (6A) 

2001 

Endeavour 

Installed ISS robotic arm 

Raffaello Multi-Purpose Logistics Module 

108 (UF-1) 

2001 

Endeavour 

ISS crew exchange 

Raffaello Multi-Purpose Logistics Module 





Figure 19 - X-38 drop tests were conducted 
at Edwards Air Force Base. 


Shuttle missions (Table 7) [3]. A cable splitter after 


GPS signal tracking is subjected to a plasma region during entry. On STS-100, plasma effects impacted 
Force 19 tracking starting at about 270,000 feet, and continuous tracking of four satellites ceased at 
around 240,000 feet. Gontinuous four-satellite tracking did not resume again until about 130,000 feet. 
The inertially aided MAGR/S receiver performed much better. For the follow-on STS-108 flight, the SIGI 
was modified so that the Force 19 could use aiding data to help reestablish satellite tracking after plasma. 
As a result, continuous four satellite tracking was regained by an altitude of 210,000 feet [3]. 
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Additional Testing 


Issues observed on the STS-100 mission 
prompted testing of the CRV SIGI on a NASA 
Beechcraft Beech 200 Super King Air at the 
Dry den Flight Research Center (Figure 20). 
This was the X-38 SIGI Atmospheric Flight 
Test, or X-SAFT. Two CRV SIGIs were carried, 
and one H-764G EGI and one Ashtech Z-12 
differential GPS receiver were on-board for 
comparison with the SIGIs. The first phase of 
13 fesf flighfs (Augusf-Ocfober 2001) was 
performed fo assess posifion and velocify 
deferminafion. For fhe second phase of 6 fesf 
flighfs (February-May 2002), four GPS anfennas 
were placed on fhe King Air fo supporf affifude 
deferminafion tests. The tests were useful for 
comparing side-by-side performance of fwo 
idenhcal SIGI unifs (for redundancy 
managemenf archifecfure decisions), validafion 
of lab fesf equipmenf, and check-ouf of 
procedures, dafa collection and commanding 
software. The test flights were unable to 
duplicate performance issues fhaf occurred on- 
orbif during fhe Shuffle flighfs of CRV SIGI. 



Figure 20 - NASA personnel conducted CRV 
SIGI tests in a Dryden Flight Research Center 
Beechcraft King Air. 


Resolving the SI Gl Attitude I nitialization I ssue 

Solving For Attitude 

Requirements for the contingency departure from ISS scenario dictated that the CRV avionics system 
must be able to solve for position, velocity, and attitude without a data transfer from Mission Control 
(Houston or Moscow) or the ISS computers (i.e. a SIGI cold start must be performed). To support a re¬ 
contact avoidance burn 22.5 minutes after departure from the ISS, cold start completion was needed soon 
after separation. Lab testing of the Force 19 indicated that it could provide position and velocity 
relatively quickly after a cold start. However, lab testing also revealed that the receiver could not always 
provide GPS derived attitude under cold start condihons in time to support the re-contact avoidance 
burn, due to the time required to solve for carrier phase infeger ambiguifies. 

Finding a Way to Compute Attitude Quickly 

Alfemafe mefhods of SIGI affifude inifializafion were sfudied. One opfion involved adding 
magnefometers fo fhe CRV, buf fechnical problems prevenfed fhis. A digifal camera system had been 
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included in the CRV design to provide the crew with situational awareness during undocking and 
separation from the ISS, until the CRV was clear of ISS sfrucfure, and could be adapted to perform an 
inifial affifude deferminafion funcfion. This sysfem was slafed for fesfing on fhe X-38 V-201 fesf flighf, 
and software and procedure development was begun so that the optical attitude determination feature 
could be tested on that flight. 

The Camera System 

Five cameras were to be mounted on the top of fhe Descenf Propulsion Sysfem (DPS), and fwo on fhe 
boffom (Figure 18). Earfh limb and nadir sightings, coupled wifh inertial rafe dafa from fhe SIGIs, would 
be used fo compufe an inifial affifude esfimafe. On fhe CRV, fhe crew could quickly perform fhe 
sightings before or affer separation from fhe ISS. Affifude esfimafes produced by this method were 
deemed accurate enough to support the collision avoidance bum. In addition, the attitude estimates 
would speed up the Force 19 integer ambiguity resolution process, which would lead to more timely GPS 
attitude determination. 

Camera Tests For V-201 

For the unmarmed V-201 flight. Mission Control would perform fhe Earfh limb and nadir sighfs on video 
fransmiffed from the X-38 to test the attitude determination algorithm. Florizon sensors were also 
mounted on the DPS of fhe V-201 vehicle fo cross check fhe digifal camera attitude solution. 


V-201 SIGI Operations Concept 

For the unmanned V-201 X-38 test flight, the three CRV SIGIs were to be activated and checked out while 
the X-38 was still in the orbiter payload bay. The Shuttle onboard star trackers and the MAGR/S, along 
with TDRSS and ground radar tracking were to be used to check SIGI attitude, position and velocity. 

After deployment, X-38 horizon sensors were to be used to check the GPS attitude computed by the 
SIGIs. GPS attitude determination was to be turned off before enfry, and fhe SIGIs would continue fo 
defermine affifude based on infegrafed rafe measured by fhe SIGI sfrapdown IMUs. SIGIs were fo 
continue fo perform position and velocity determination until landing. 

A back-up navigation function was designed into the X-38 software in the event of SIGI problems. Back¬ 
up navigation was to be initialized using a selected SIGI blended position and velocity vector. SIGI 
strapdown IMU sensed delta-velocity data was to be continuously used to propagate the backup state 
vector. Starting at an altitude of -80,000 feef (-Mach 2.5), baromefric alfifude dafa from fhe Flush Air 
Dafa Sysfem was to be incorporated by backup navigation to control vertical position errors. Backup 
navigation could be reinitialized using a selected SIGI blended state vector if Mission Gonfrol personnel 
deemed fhaf errors in fhe backup sfafe vecfor were excessive. 
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To support landing, a radar altimeter was to provide more accurate altitude than SIGI from 5,000 feet 
through touch down. Further definition of navigafion archifecfure and procedures for fhe operafional 
CRV was fo be made based on V-201 flighf resulfs. 
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11. Rationale Behind a Notional Shuttle GPS Receiver Upgrade 


Prior to the decision to retire the Shuttle by 2010, consideration was given to replacing the Space Shuttle's 
mid-1990s vintage 5-channel receiver with a more modem, all-in-view tracking receiver. This chapter 
details some of the ways advanced GPS technology could have been leveraged to improve Shuttle 
navigation, and some reasons why advanced GPS technology would not have changed some aspects of 
Shuffle navigafion. 


The currenf receiver represenfs an early 1990s fechnology level. Alfhough if has flown on fhe Shuffle 
since 1996, and been cerfified for use during flighf, newer GPS unifs, GPS safellifes and augmenfafion 
sysfems are enfering (or will soon enfer) service wifh more advanced capabilifies. Some of fhese 
capabilifies could be leveraged fo improve Shuffle navigafion and safety, particularly if new aufomafion 
or autonomy requiremenfs emerge (Figure 21). A sfudy would be required fo determine which advanced 
capabilifies would provide benefif fo fhe Shuffle Program. Idenfificafion of candidafe replacemenf 
receivers would be confingenf on when new safellife navigafion capabilifies are infroduced, and when 
receivers fhaf fake advanfage of fhose new feafures are available. This secfion discusses several ways in 
which GPS could be applied fo fhe Shuffle, buf nof all of fhe concepfs menfioned are desirable for fhe 
vehicle. 


Legacy Sensors 

Orbit Absolute Nav Orbit Relative Nav 


•3 IMUs 
• Ground Radar 


■3 IMUs 

' 2 Star Trackers 


' 2 Star Trackers 
' Ku Band Radar 


Entry & Landing 


■ 3 TACAN & 1 
GPS or 3 GPS 



' Facilitates Autoland 
' Lower Minimum Ceilings 
' Improved Integrity 
' Safer Emergency Landings 


Modern GPS Receiver 


Figure 21 - Legacy Navigation Sensors By Flight Phase, With Potential Advantages of a Modern Receiver. 
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Receiver Recovery 


Modern GPS receivers can track 12 or more GPS satellites at a time. This greatly speeds up state 
determination after a power cycle or receiver software reset, and reduces the likelihood that difficult 
tracking conditions will result in unavailability of fhe GPS navigation solution. This would provide a 
performance improvemenf over fhe currenf five channel Shuffle GPS receiver. 


Loss of Service 

The five channel unif certified for use on the Shuttle uses four channels fo obfain GPS measuremenfs, and 
a fiffh for ephemeris collection, measuremenf collection for correction of ionospheric errors, fracking 
channel calibration and safellife acquisition. New safellifes needed to maintain track of an opfimal sef of 
four are acquired sequenfially. Under difficulf fracking condifions (mulfi-pafh, anfenna obscurafion, 
safellife line-of-sighf off of fhe anfenna gain paffern), mulfiple safellife swifches could fail or be delayed, 
resulting in less than optimal satellite geometry or less than four safellife tracking for exfended periods of 
time. 

In some cases during fesfing, fhe receiver's esfimafe of ifs posifion accuracy exceeded a Shuffle compufer 
GPS qualify assurance fesf limif, which would have prevented the Shuttle computers from using posifion 
and velocity data from thaf receiver. The lengfh of fhe GPS oufages varied. An exfensive ground fesf 
efforf was conducfed fo ensure fhaf loss of a GPS receiver during enfry due fo fhis condition would nof 
compromise safefy of flighf. 

An all-in-view receiver (capable of fracking 12 or more safellifes at a time) would be more capable of 
providing a navigation solution under difficulf fracking condifions. 


New GPS Signals 

Gurrent GPS safellifes broadcasf fwo milifary signals and one civilian signal, all of which can be hacked 
by fhe Shuffle GPS receiver. New GPS safellifes, which will be launched in fhis decade, are fhe Block IIR- 
M and Block IIP series [111, 112]. 

In addition fo fhe fhree legacy signals, fhe Block IIR-M safellifes will broadcasf fwo new aufhorized user 
signals, a new civil signal, and all signals will be broadcasf at a higher power level than the previous GPS 
satellites (Figure 22). The Block IIP satellites, will broadcast those signals transmitted by the Block IIR-M 
vehicles, as well as a third civil signal to support safety-of-life applications, such as aircraft. The current 
Shuttle receiver will be able to track legacy signals transmitted by the Block IIR-M and Block IIF satellites, 
but a new GPS receiver will be required to take advantage of fhe additional signals and fhe improvement 
they provide to navigation integrity. Early in the next decade, the next generation GPS satellite, GPS III, 
may be entering service. This satellite and its new architecture may possess newer signals, enhanced 
reliability and accuracy. 
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Satellites 


Block IIR-M Satellites 


Block IIP Satellites 


Galileo 


GPS III 


• M code on L1 & L2 

• Civil signal on L2 

• Higher power 

• First launch 2005 


• L5 safety of 
life signal 

• Longer lifetime 

• First launch 2007? 


' European controlled 
' 30 satellites 
' Projected full 
operational 
capability -2008 


• Fifth generation GPS 

• Architecture designed to 
support the long term 

• Improved accuracy 
& reliability 

• New signals? 

• First launch 2013? 


Space or Ground Based Augmentation 


WAAS 

• Satellite broadcast 

• Enhances GPS accuracy & 
integrity in North American 
airspace 

• Ranging, differential 
correction and integrity 
signals 

• Supports take-off through 
CAT I approach 

• Initial Operating Capability 
7/10/2003 

• Final capability -2008 


EGNOS 

• European equivalent 
of WAAS 

• Monitors GPS, GLONASS 
& Galileo (future) 

• Covers Europe, with possible 
expansion to Africa 

• Safety of life certified -2006 


Future WAAS/EGNOS 
Compatible Systems 

• Japan 

• India 

• Others 


JPALS 

• Ground or ship broadcast 

• High accuracy & integrity 

• CAT I, II & III all weather 
approaches 

• Naval and land versions 
under development 

• Naval version will support 
automated carrier landings 

• Civilian version (LAAS) 
under development 


Figure 22 - Upcoming Enhancements to Global Navigation Satellite Systems 


Receiver Autonomous I ntegrity Monitoring and Satellite Based Augmentation 

The level of GPS navigation solution accuracy, availability and continuity are important, in addition, the 
integrity of the navigation solution, whether or not it can be trusted, is critical [113]. The integrity of the 
GPS navigation solution is dependant on the on-board GPS receiver, the GPS satellites and the GPS 
ground support infrastructure. 

Gurrently, the Shuttle Program is dependent on the GPS Master Gontrol Station (MGS) for notification of 
malfunctioning satellites. If the MGS cannot set the satellite health bit or change the satellite GPS signal 
to be non-trackable, the MGS would pass word of the malfunctioning satellite to Mission Gontrol. Based 
on Mission Gontrol instructions, the crew would perform a data entry into a Shuttle computer display to 
instruct the GPS receivers to ignore the unhealthy satellite. 

The all-in-view tracking capability of modem receivers facilitates the use of Receiver Autonomous 
Integrity Monitoring (RAIM), which detects anomalous GPS signals and identifies suspect GPS satellites, 
facilitating exclusion of their measurements from state vector determination. The availability of RAIM 
would provide a level of protection against spurious GPS signals that is not available today with the 
Shuttle's five-channel receiver. 

While RAIM provides protection against suspect satellites, there may be times when a receiver is tracking 
an insufficient number of GPS satellites with suitable geometry to support RAIM. Satellite or ground 
based augmentation using ground monitoring stations can provide a higher level of "real time" integrity 
protection than a stand-alone GPS receiver employing RAIM [113]. 
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The U.S Wide Area Augmentation System (WAAS) and European Geostationary Navigation Overlay 
Service (EGNOS), which are satellite based augmentation systems (the augmentation signals are 
broadcast by satellites other than the GPS satellites), will provide GPS satellite integrity information to 
those GPS receivers capable of receiving WAAS and EGNOS signals (Figure 22) [114]. WAAS and 
EGNOS navigation payloads on geosfafionary safellifes broadcasf ranging, differenfial correcfion and 
safellife infegrify signals. This will enable receivers fo exclude safellifes of questionable qualify. The 
additional ranging signals will improve solufion qualify and availability. 

WAAS covers most of Norfh America wifh GPS correcfions and infegrify signals, while EGNOS 
broadcasfs GPS and Global Navigation Safellife Sysfem (GLONASS) relafed dafa fo Europe. EGNOS 
could be expanded fo cover Africa, and will evenfually broadcasf Galileo relafed dafa. Ofher counfries 
such as Japan and India are considering building sysfems fhaf perform fhe same funcfion as, and are 
compafible wifh, WAAS and EGNOS. 

Receiver based RAIM and access fo infegrify dafa from safellife based GPS augmenfafion sysfems would 
permif a modem GPS receiver fo exclude a questionable safellife in an autonomous manner, more 
quickly than can be done with the legacy five channel receiver. 


Shuttle Autoland Using Ground Based GPS Augmentation 

The Shuffle was designed wifh an aufoland sysfem, which has been upgraded over fhe years [115, 116]. 
However, a completely automatic landing has never been affempfed, and fhe capabilify is a back-up 
flying mode for contingencies. 

The Shuffle's MLS is an integral parf of the Shuttle's autoland capability. It has been successfully used fo 
supporf pilofed landings since fhe beginning of fhe Shuffle flighf program in 1981 [117]. The Shuffle MLS 
sysfem is differenf fhan fhaf used fo supporf civil aviation, and is only available af six Shuffle landing 
sifes.’^ The Shuffle has a much steeper glideslope fhan aircraff. Over fhe long term, fhere are difficulties 
in mainfaining fhe legacy MLS on-board and ground equipment. Multi-path and coverage issues are also 
of concern wifh MLS supporf for aufoland. 

If aufomafed landings of eifher a crewed or uncrewed Shuffle are desirable in fhe fufure, use of a ground 
based GPS augmenfafion sysfem (augmenfafion signals are broadcast by a ground station) employing the 
differential GPS concept may be preferable over MLS. A ground-based augmentation system could 
provide a navigation solution of sufficienf accuracy and infegrify, provide more operafional flexibility in 
landing site selection, and enhance safety margins. 


* Within the Shuttle Program, the name Microwave Scanning Beam Landing System (MSBLS) is often used to 
differentiate the Shuttle system from the civil and military aviation Microwave Landing System. 
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The military Joint Precision Approach and Landing System (JPALS)* will provide high accuracy, high 
integrity differential GPS navigation to support precision landing in all weather conditions [5, 118-123]. 
Tests of a profofype JPALS sysfem have already supporfed aufomafed F/A-18 carrier landings and 
Unmanned Aerial Vehicle (UAV) fests [119, 121]. JPALS will play an imporfant role in fufure UAV 
operafions [122]. One sef of JPALS ground equipmenf could service all fhe runways af a landing sife, 
while fhe legacy MLS equipmenf has fo be positioned af each runway. This would ensure availabilify of 
precision landing capability no matter which landing site runway was selected. 

Use of JPALS would require a new GPS receiver. The legacy receiver was nof required fo, nor does it 
support, precision landing using GPS augmentation. 


Weather Minimums For Landings 

Use of an all-in-view receiver wifh JPALS and RAIM may also permit reduction of minimum ceilings, 
and provide more safety margin for emergency landings, whefher fhey are pilofed or aufomafed. 


Simplification of Shuttle Navigation Procedures 

A more capable and robusf GPS receiver could lead fo fhe simplificafion of Shuffle on-board and Mission 
Gonfrol navigation procedures. However, any such simplification would have to be proceeded by an 
extensive analysis of currenf procedures, program requiremenfs and flighf rules. Furfhermore, each 
proposed change should be examined fo defermine if fhe payback in ferms of life cycle cosfs and risk 
reduction justifies fhe change. 

The firsf measuremenf processed during enfry is drag alfifude, compufed using Inerfial Measuremenf 
Unif dafa and an afmosphere model. Drag alfifude infroduces an expecfed level of alfifude error info fhe 
Shuffle navigation sfafe, buf bounds alfifude errors fhaf are common fo inerfial navigation sysfems. All- 
in-view fracking, RAIM and safellife infegrify signals from safellife-based augmenfafion could eliminafe 
fhe need for drag alfifude measuremenf processing. 

A ground compufed correcfion fo fhe Shuffle on-board navigation sfafe, called a delfa sfafe updafe, is a 
backup fo the on-board navigation system. This capability requires two ground radars, a good Mission 
Gontrol solution of fhe Shuffle sfafe vecfor, and a commanding capabilify to put the delta-state into the 
Shuttle computers. Given the integrity functions available to more advanced GPS receivers (WAAS, 
JPALS, RAIM, more signals), dependence on the delta state backup capability could conceivably be 
reduced. 


A civilian equivalent, the Local Area Augmentation System (LAAS), is under development. 
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Barometric altimeters provide altitude measurements for Kalman filter processing by the Shuttle primary 
and backup computers. Given that barometric measurements help bound altitude errors at lower 
altitudes and are more accurate than the previously mentioned drag altitude measurement, it is unlikely 
that barometric altitude processing would be eliminated. Such a measurement would still be desirable in 
the event of one or more Shuffle sysfems problems fhaf resulf in an unavailability of GPS dafa. 
Furfhermore, fhe pifof fubes fhaf provide fhe baromefric alfifude measuremenf also provide dafa from 
which several paramefers are derived for fhe orbifer's flighf confrol sysfem. 


Precision Orbit Determination 

The Shuffle MAGR and ISS Force 19 GPS receivers did nof have requiremenfs fo supporf precision orbif 
deferminafion. While fhe exisfing fibers in fhese receivers do meef requiremenfs, flighf resulfs show fhey 
are nof capable of precision orbif deferminafion [23]. This funcfion is currenfly performed for fhe Shuffle 
by Mission Gonfrol, and for fhe ISS by fhe U.S. Air Force Sfrafegic Gommand and fhe Ballistics 
Navigation Sysfem group af fhe Russian Mission Gonfrol in Korolev. These solutions are used fo supporf 
maneuver planning and debris avoidance. A Mission Gonfrol based filler, called SPOT (Spacecraff 
Position Opfimal Tracking) has been developed fo perform precision orbif deferminafion using MAGR 
and Force 19 position vectors. Gonsiderafion could be given fo providing a precision orbif deferminafion 
capability on-board the orbiters. This could be done by placing a suitable filtering algorithm in either a 
GPS receiver, or in a computer external to the receiver. It may be easier to place the orbit determination 
filter in a computer other than the GPS receiver. 


Rendezvous and Proximity Operations 

Application of relative GPS is being pursued by developmenf efforfs for fhe European Automated 
Transfer Vehicle (ATV) and fhe Japanese FI-II Transfer Vehicle (FITV). Similar application could be 
considered for fhe Shuffle as a rendezvous radar replacemenf. 

The Shuffle has a requiremenf fo rendezvous wifh vehicles fhaf are nof equipped wifh active relative 
navigation aids such as relative GPS. Any replacemenf of a currenf relative sensor wifh relafive GPS 
would have fo be exfensively sfudied fo ensure fhaf fhe Shuffle could still rendezvous wifh 
navigafionally passive fargefs. 

To supporf relafive GPS for Shuffle rendezvous wifh fhe ISS, a new communications link befween fhe ISS 
and Shuffle may have fo be created, wifh additional hardware and soffware added fo bofh vehicles. The 
ISS may also need a new GPS receiver, modified fo meef a relafive GPS requiremenf. The currenf ISS 
receivers, and fhe Shuffle's currenf GPS receiver, were nof inf ended fo meef a relafive GPS requiremenf. 


Relafive GPS could conceivably replace fhe rendezvous radar and sfar frackers in fheir relafive sensor 
roles. Such a replacemenf would permif similar navigation sensor redundancy (fhree GPS receivers 
versus one radar) and eliminafe fhe need for radar failure relafive navigafion procedures. The Ku Band 
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antenna and associated electronics would still be required to support transmission of data and video via 
the TDRSS network satellites. In the event of a fufure communicafions sysfem upgrade fhaf replaces fhe 
Ku Band hardware communicafions funcfion, replacemenf of fhe Ku Band rendezvous function by 
relative GPS would be desirable. The sfar frackers used for relafive opfical measuremenfs are also used 
for IMU alignmenf, and would have fo be refained in fhe evenf of a swifch fo relafive GPS. 

Accuracy, mulfi-pafh, reliability, anterma obscuration and sensor measurement redundancy concerns in 
close proximity to the ISS would prevent relative GPS from replacing fhe laser sensors currenfly in use fo 
supporf fhe close approach and docking phases. 

A GPS receiver fhaf is fo be used for relafive navigation would require exfensive modification of 
navigation and filfering algorifhms. If fhe receiver could nof be modified, GPS measuremenfs could be 
passed fo an on-board compufer fhaf has navigafion and filfering algorifhms specifically designed fo 
supporf relafive navigafion during rendezvous and proximity operations. Relative GPS is also more 
complex than other relative sensors. Given the complexity of fhe Shuffle and ISS GPS infegrafions, a 
relafive GPS infegrafion efforf should nof be considered fo be sfraighfforward. 


Attitude Determination 

Research info GPS affifude deferminafion has been exfensive, and such an application has been 
operafional on fhe ISS since April 2002 [2]. However, for fhe Shuffle, GPS affifude deferminafion is nof 
desirable. 

Multiple anfermas are required for GPS affifude deferminafion, and fhe ISS experience has shown fhaf 
affifude solution qualify is dependenf on safellife visibilify fo fhe anferma array, which is a funcfion of 
vehicle affifude. Mounfing arrays on fhe Shuffle fo ensure adequafe visibilify would be problematic. The 
Shuffle IMUs provide high accuracy affifude dafa during all phases of flighf, af any affifude. The unifs 
are aligned using sfar frackers. The high accuracy is needed fo supporf safefy critical ascenf and enfry, 
where excessive affifude errors are nof permissible. GPS affifude deferminafion may nof be of sufficienf 
accuracy fo replace fhe sfar frackers in fhe role of supplying affifude updafes fo fhe flighf compufers, for 
fhe purpose of IMU alignmenf. 


GPS Metric Tracking For Range Safety 

An efforf fo replace legacy ground radars wifh on-board GPS receivers for range safefy af U.S. launch 
sifes has been underway for some fime. Range safefy fracking requires fwo independenf sources of 
fracking dafa. The Shuffle GPS receiver is infegrafed wifh fhe on-board navigafion, guidance and flighf 
confrol sysfem. This would preclude fhe use of a new Shuffle GPS receiver from being used fo reduce 
required ground fracking supporf during launch. An additional GPS receiver, independenf of fhe Shuffle 
avionics sysfem, would be required fo meef range safefy requiremenfs for fhe Shuffle orbifers. Ground 
radar replacemenf for range safefy would also require fhe addition of GPS receivers fo fhe Solid Rockef 
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Boosters. In addition to range safety, ground radar tracking is required to support Shuttle launch and 
landings, which includes nominal and emergency landings at the Kennedy Space Center Shuttle runway. 
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12. Summary 


In the early 1990s, GPS was viewed as an off-the-shelf fechnology fhaf would permif a fasfer-beffer- 
cheaper approach fo upgrading vehicles and lowering developmenf cosfs. GPS fechnology has been 
successfully infegrafed info fhe Infernafional Space Sfafion and fhe Space Shuffle (fhe X-38/GRV projecf 
was canceled). GPS provides more operational flexibility and better accuracy than legacy navigation 
aids. 

However, the number of fechnical issues encounfered exceeded fhe expecfafions held af fhe sfarf of fhe 
projecfs. The amounf of time, number of personnel, and efforf required fo resolve fhese fechnical issues 
exceeded initial esfimafes. GPS receivers are complex compufers fhaf inf erf ace wifh ofher complex 
compufers. Treating a GPS infegrafion wifh a spacecraft avionics sysfem as a sfraighfforward "plug and 
play" projecf will lead fo multiple fechnical, cosf and schedule problems. 

Exfensive fesfing of inferim software versions and fhe infegrafed sysfem should be performed, bofh in 
fhe lab and fhe acfual operating environmenf. Gompufer inferfaces, including GPS receivers, in safefy- 
crifical sysfems should be "bullef proofed" fo profecf againsf known and posfulafed forms of spurious 
inpuf. Redundancy, RAIM, safellife and ground based augmenfafion and moniforing sysfems will nof 
profecf againsf sysfem level problems, receiver software problems, or user errors. While if is a good idea 
fo equip GPS receivers wifh an autonomous resef feafure ("cfrl-alf-delefe"), fhe exisfence of such a feafure 
should nof be used as an excuse fo fake shorfcufs in software and sysfem developmenf and fesfing. 
Widespread accepfance, confidence in, and use of GPS fechnology should nof lull fhe infegrafion and 
user communify info fhinking fhaf problems cannof occur, particularly af fhe receiver level. Research 
and fesfing is needed fo characferize receiver failures, and fheir probabilify of occurrence. 

Infegrafion and use of software infensive, off-fhe-shelf unifs info safefy related applications for which 
fhey were nof originally designed requires vendor supporf and design insighf above fhaf required for 
ofher off-fhe-shelf integrations. Open communicafion among all parficipanfs and close relationships 
wifh navigafion unif vendors are required fo ensure success. 

The process issues encounfered by GPS vendors, infegrafors, users, and cerfificafion aufhorifies are nof 
specific fo fhe navigafion indusfry. The same issues occur fhroughouf fhe compufer indusfry, and are fhe 
subjecf of research and discussion af compufer indusfry conferences. Inferacfion befween fhe compufer 
software and fhe navigafion indusfries may help overcome GPS software process problems. 

Nof all fechnical difficulties wifh new fechnology should be inferprefed as being process problems (lack 
of communicafion, inadequafe requiremenfs, insufticienf fesfing). Application of new and revolutionary 
fechnology fo new operafing environmenfs is a process of discovery. The Golumbia Accidenf 
Investigation Board characferized fhe Shuffle as being a developmenfal vehicle wifh an operafional 
mission. The NASA JSG experience wifh GPS in space indicafes fhaf if foo is developmenfal in nafure, 
wifh an operafional mission. 
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